O que faz uma pessoa atacar seu sistema?

Vamos lá, você é aquele desenvolvedor focado, construindo o próximo unicórnio da tecnologia, e de repente, do nada, seu site começa a ser atacado. Aí vem a pergunta que não quer calar: Por que alguém perderia seu precioso tempo atacando o meu site? Será que essas almas mal-intencionadas não têm nada melhor para fazer?

O Papel Salvador da LGPD

Mas calma, porque a LGPD está aqui para proteger você — o dono do site, o desenvolvedor honesto que está só tentando inovar. Graças a essa maravilhosa lei, nós podemos coletar o IP dos visitantes! Sim, aquele mesmo IP que esses seres "espertos" acham que ninguém vai notar. Cada movimentinho que eles fazem fica registrado. E sabe o que podemos fazer com isso? Bloquear eles, claro, porque a LGPD não é só sobre proteger o usuário final, é também sobre garantir que você, o dono do site, saiba quem está tentando bagunçar sua festa e assegurar a proteção de todos os dados do seu sistema.

"Ah, mas e a privacidade?"

Ah, privacidade... aquela palavra bonita que todos adoram repetir. Claro, estamos aqui para proteger a privacidade dos bons usuários. Mas se o cara veio aqui para atacar? Desculpa aí, mas a LGPD nos dá o direito de manter esses dados "sensíveis" (como o IP) guardadinhos por segurança. Afinal, quem não adoraria uma bela sessão de logs cheios de IPs suspeitos prontos para serem bloqueados? Nada mais justo!

E enquanto isso, o cara mal-intencionado? Ele está lá, achando que é o gênio da cibersegurança, enquanto seus dados já estão bem armazenados no nosso sistema, protegidos pela... LGPD. Se for o caso, já sabemos a quem responsabilizar quando as coisas esquentarem.

Então, da próxima vez que alguém tentar atacar o seu site, relaxe. A LGPD está do seu lado. Você pode rir dos esforços desses amadores, sabendo que seus logs de IP estão bem guardados, e que a lei está do seu lado quando precisar bloquear ou reportar essas criaturas que, por algum motivo, ainda não arranjaram nada melhor para fazer.

Ataques Complexos: DDoS e os "Caçadores de Falhas"

Porque, claro, nada diz "sou um gênio da computação" mais do que derrubar um site com um DDoS. Quem nunca ouviu falar dessa gloriosa técnica onde o sujeito lança um monte de requisições falsas no servidor e se senta para assistir o caos acontecer? O hacker amador pensa que está sendo brilhante, mas a verdade é que... bem, a gente está vendo tudo, amigo.

DDoS? Sério? Você acha mesmo que os donos do site vão ficar de braços cruzados enquanto sua brilhante "invasão" tenta sobrecarregar nossos sistemas? Bom, enquanto você está achando que está causando, nossos logs de rede, cortesia da LGPD, estão colecionando todos os seus IPs sujos e preparando o banhammer. Ah, e obrigado por gerar tráfego extra! O Google Analytics adora números inflados — parece até que nosso site está bombando de tanto acesso.

Os "Caçadores de Falhas"

E o que dizer dos caçadores de falhas? Aqueles que passam horas, quem sabe dias, tentando encontrar uma brecha mínima para explorar. Eles pensam que estão desbravando o El Dorado das vulnerabilidades, quando na verdade estão só entregando mais material para os logs. Mas pode continuar, estamos adorando o show!

Cada linha de código inspecionada, cada exploit frustrado... tudo devidamente registrado. Acham que ninguém está olhando enquanto testam todas aquelas senhas, métodos HTTP obscuros ou tentam injetar SQL no campo de login? Hahaha! Aqui vai um spoiler: nós vemos tudo. A cada requisição estranha, a gente dá risada e pensa: "Lá vem mais um tentando a sorte..."

O Grande Segredo: Estamos Observando 👀

Então, aos nossos queridos "hackers avançados", lembrem-se de uma coisa: estamos sempre vendo. Cada ataque, cada tentativa de exploração, cada script malicioso que você roda achando que é invisível — está tudo registrado. Então, da próxima vez que você achar que está sozinho tentando derrubar ou hackear um sistema, saiba que tem sempre alguém com uma xícara de café, rindo e monitorando todos os seus movimentos.

E o melhor de tudo? A LGPD nos garante o direito de ficar de olho em você. Então, continue tentando, a diversão é garantida... para nós.

Se você sabe tanta computação que tá com tempo livre pra atacar sites, talvez seja a hora de usar esse talento pra algo mais desafiador... tipo, arrumar um emprego CLT.

Abraços para meu IP favorito, que quase todo dia entra no meu sistema para fazer alguma coisa.

Att, oxygenfront

user1ontem

Tenho a sensação que isso foi quase um desabafo.

oxygenfrontontem
Olá, user1! Fico feliz que meu artigo tenha gerado essa "reflexão"! Realmente, é difícil não se sentir desabafado quando você, com tanto amor, desenvolve um site e se depara com esses "técnicos de informática" que acham que a vida é um videogame. E quem diria que a LGPD seria nosso "guarda de segurança"? Quase poético! Cada ataque é um movimento nesse jogo de xadrez, onde os "caçadores de falhas" pensam que são gênios, mas estamos sempre um passo à frente (ou não). Talvez um dia esses "hackercitos" percebam que um emprego CLT é a verdadeira conquista da vida real. Afinal, quem precisa de crescimento profissional quando se pode inflar o ego derrubando servidores? Obrigado por lembrar que, mesmo quando desabafamos, sempre dá para rir das nossas "aventuras" na tecnologia. Continue refletindo. Att, oxygenfront
Allveszhá 6 horas

Fala man, sou um analista de segurança e to começando a entrar no mundo de programação. Achei um post interessante, mas temos algumas ferramentas que podemos utilizar pra pegar um ip de outro lugar, por exemplo o nipe/tor do github. Um colega meu que desenvolveu, muito bom por sinal. Então mesmo que você colete os IPs e coloque ele pra ser bloqueado no seu firewall ou algo assim, não adianta muita coisa. Podemos alterar os ips novamente e tentar de novo kkkk. Mas entendo que é frustrante mesmo você subir uma aplicação e ser atacado/invadido. Claro que temos outros métodos para poder realizar os ataques também, mas a LGPD não é tudo isso não kk. Mas claro, ja da uma ajuda.

dealmeidahá 21 horas

boa tarde, sr.

na camada de aplicação, tudo pode acontecer.

percebi que esse assunto é importante para nós dois.

a depender da aplicação que estejamos discutindo, é mais viável já identificar e autenticar os usuários diretamente da fonte, com VPN, na camada de rede.

com o sr, aprendi que há muitas coisas a serem revistas. por isso, refleti.

manter os logs deveria ser obrigatório, para fins de estratégia em cibersegurança (padrões de ataque) e auditoria (novas políticas internas, etc), durante o caos e após.

porém, quais soluções o sr proporia para aplicações web 100% públicas?

em minhas vps linux, prefiro implementar rate limiting diretamente no nginx, sem contar o balanceamento de carga, e pensando na resiliência e capacidade de sobrevivência dos componentes em minhas arquiteturas. implementar alguma solução que reconhece padrão de ataques e os insira em uma blacklist no ufw ou com fail2ban valem a pena. por exemplo, após atingir 3 vezes o rate limiting no mesmo minuto já seria 100% de justificativa para banir, mesmo. há como configurar outros padrões. se a aplicação é acessada em ddos pelo estrangeiro, reduza-se a rede de ips à nacional. se a aplicação é acessada nacionalmente em ddos, já é uma desvantagem para o atacante. não vejo outra saída senão já ter implementado uma pré-autenticação de dispositivos quando, em tempos de paz, todos acessavam normalmente. por exemplo, enviar tokens específicos que identificam o dispositivo.

monitoramento também é fundamental, para acompanhar e agir. da máxima da administracão, só se administra e se controla aquilo que se mede com indicadores e métricas bem definidas.

porém, além de tudo o que falei, sabendo que não falei nenhuma bala de prata, o que mais poderia ser feito? sem utilizar plataformas como serviços de terceiros.

pensei em reduzir mais ainda a superfície de ataque fazendo um hardening do linux, endurecer mais as políticas, manter dependências atualizadas, confinar a aplicação em conteineres. criar alguns honeypots estratégicos é interessante. o sr poderia contribuir-nos com alguns?

já ouvi falar de snort, suricata e modsecurity, só nunca implementei (ids/waf).

tentei falar de maneira menos acadêmica, porém o conteúdo em si da teoria já é diferente da prática. mesmo assim, espero que o sr entenda destas palavras que escrevo.

é bom saber disso tudo.

aguardo um retorno.

oxygenfronthá 2 horas
Boa tarde, sr! Vejo que temos um entusiasta da "Segurança para Todos e Todas", e o mais fascinante é a sua jornada rumo ao "nirvana cibernético", onde cada pacotinho de rede é um soldado em uma batalha épica contra as hordas de malfeitores digitais. Vamos, então, à nobre pergunta: o que fazer com aplicações web 100% públicas sem terceirizar a alma para serviços externos? Rate limiting no Nginx? Belíssimo, diria eu. Um verdadeiro ballet de throttling, onde cada requisição indesejada é suavemente desacelerada até o ponto de asfixia digital. O fail2ban está aí para trazer o banimento em três atos: primeiro ato, uma piscadela de advertência. Segundo ato, uma leve bronca. E no terceiro? Banimento eterno. Para o atacante, é quase como se a infraestrutura fosse uma opera onde ele sempre morre no fim. Agora, reduzir a superfície de ataque para uma VPS Linux? Ah, chef’s kiss! Eu até imagino o hardening sendo aplicado com a delicadeza de um escultor moldando o aço de políticas rigorosamente blindadas (gostou da analogia?). Acha que um atacante vai explorar vulnerabilidades num sistema containerizado? Claro que não! Eles só vão encontrar conteineres isolados que sequer sabem da existência uns dos outros, enquanto nossa aplicação vive feliz na sua namespace fortificada. Você mencionou DDOS nacional? Sim, claro, porque nada diz “respeito pelo meu tempo” como um ataque vindo de dentro das nossas próprias fronteiras. E aí vem a ideia brilhante de pré-autenticação de dispositivos. Quem disse que só quem tem passaporte precisa de identificação? Eu digo: seu dispositivo pode ter um token como um crachá VIP, já autorizado a passar por todos os checkpoints enquanto os amadores batem a cara na parede. Mas sabe o que realmente aquece meu coração? Honeypots estratégicos. Aquela doce armadilha digital, brilhando de longe como uma utopia para os hackers que, ao invés de encontrar brechas no seu sistema, encontram… nada. Eles exploram, escaneiam e, no fim, saem com um grande zero à esquerda. Enquanto isso, nós, os administradores, estamos apenas registrando tudo em tempo real, como se estivéssemos assistindo a um show de mágica onde o truque final é: Surpresa! Você foi pego! E claro, você mencionou os aristocratas dos IDS/WAFs: Snort, Suricata, ModSecurity. Ferramentas cujo mero nome já faz os atacantes suarem frio. Eu também nunca implementei. E talvez nem precise! Porque afinal, o verdadeiro segredo aqui é manter todos pensando que você tem uma infraestrutura que parece saída de uma fantasia tecnológica, com múltiplos failovers, redundâncias mirabolantes, tudo rodando em uma camada etérea de segurança quântica (ou talvez, apenas VPN com autenticação multifatorial). Então, caro amigo, a resposta final é essa: continue com esse seu mindset. Segurança cibernética é como um bom vinho, amadurecendo a cada atualização de kernel e banimento de IP. Não existe bala de prata, mas quem precisa de balas quando temos uma boa taça de logs e a LGPD nos oferecendo proteção, saca? Encerro aqui com um grande abraço para os atacantes que continuam a nos divertir. Ah, e claro, sucesso na sua próxima implementação de VPN com rate limiting ao quadrado! Afinal, quando falamos de cibersegurança, "o caos sempre encontra uma nova maneira de nos surpreender". Talvez seja a entropia da segurança, não? Att. oxygenfront
HarukaYamamoto0ontem

São uns artigos assim que eu gosto, um autor que realmente sabe do que tá falando, e responde os comentários usando bons argumentos

oxygenfronthá 8 horas
Obrigado pela análise e feedback! Existe muito estudo e um trabalho por trás! Gosto de literatura como hobby tbm, por essa razão quero adotar uma escrita com personalidade para ajudar ao leitor ir até o final do texto. Fico feliz com seu feedback e vou tentar manter esse compromisso para os próximos! Estou cansando de publicações genéricas, vazias de GPT! vlw 😃
Emersin7xontem

em dúvida se isso é um desabafo ou uma declaração de amor ao seu IP favorito kkkk. Que texto caótico e debochado kkkkk, muito bom.

Mas realmente, é um povo que se acha o crânio da tecnologia por coisas bestas e depois fica espalhando pro pessoal: "Eu sou hacker >:D", mas na verdade é uma vergonha

oxygenfrontontem
Haha, exato! Esses "script kiddies" se achando os novos Linus Torvalds, mas mal conseguem compilar um código! É uma verdadeira comédia ver como eles acreditam que clicar em “enviar” em um script de 5 linhas mal feito os transforma em mestres da hacking. No fundo, são só figurantes. E ainda por cima, o Google Analytics ama esses acessos! No fim das contas, a única coisa que eles estão hackeando é a própria vergonha na cara!
Pilationtem

"sou um gênio da computação" mais do que derrubar um site com um DDoS

especificando um pouco mais as nomenclaturas:

DoS

Ataque de negação de serviço

Quando uma pessoa faz diversas requisições para um site

DDoS

Ataque de negação de serviço distribuído

Para fazer esse ataque precisa de milhares de bots atacando ao mesmo tempo. Não é mais um serviço amador.

Simples de prevenir

Só colocar seu IP atrás da cloudflare com a opçao "proxied" ligada. A própria cloudfalre basrra esses ataques com alguns cliques

oxygenfrontontem
Derrubar um site com DDoS realmente é a primeira linha do manual do *script kiddie*, mas vamos lá. Vamos especificar as coisas um pouco mais... ### DoS (Denial of Service) Sim, enviar um monte de requisições para um site até ele ajoelhar é, de fato, um ataque de negação de serviço. Simples e, francamente, até divertido se você estiver preso nos anos 90. ### DDoS (Distributed Denial of Service) Aqui é onde a brincadeira começa a ficar mais complexa: a ideia é usar uma **rede distribuída de bots** para fazer o ataque. Não precisa ser gênio (ou talvez precise?) para saber que coordenação de milhares de bots já é um passo além. Aqui não estamos falando só de "requisitar uma página", estamos falando de saturar a largura de banda, exaurir recursos de CPU, memória, etc. ### "Simples de prevenir" Ah, sim, claro. *"Simples de prevenir"*. Só joga o sitezinho na Cloudflare, marca a caixinha "proxied" e pronto, problema resolvido, né? Isso até o primeiro ataque *Layer 7* bem feito. A Cloudflare é boa, sem dúvida, mas temos de ponderar, te garanto que não é bala de prata, principalmente se quem está do outro lado sabe o que está fazendo. Ah, sim, claro. *"Simples de prevenir"*. É só jogar o site na Cloudflare, marcar a caixinha "proxied" e voilà, problema resolvido, certo? Até que vem o primeiro ataque *Layer 7* bem elaborado. A Cloudflare é uma ótima ferramenta, sem dúvida, mas vamos ponderar um pouco sobre o que realmente significa ser “bala de prata”. ### Por que a Cloudflare não é exatamente uma bala de prata: 1. **Ataques *Layer 7***: Ah, os ataques no nível de aplicação! Enquanto a Cloudflare pode ser ótima para tráfego malicioso em camadas mais baixas, um ataque bem direcionado na camada de aplicação pode passar pela proteção. Se o atacante conhece os pontos fracos da aplicação, o simples proxied não vai salvar o dia. 2. **Configuração inadequada**: Só porque você ativou o proxied, não significa que você configurou tudo corretamente. As opções de segurança precisam ser ajustadas de acordo com o seu caso de uso específico. Caso contrário, é como tentar usar um escudo enquanto deixa as portas abertas. 3. **Falsos positivos**: Com uma proteção robusta vem a responsabilidade. A Cloudflare pode acabar bloqueando usuários legítimos, ou seja, você pode acabar bloqueando seus clientes enquanto tenta proteger seu site. Uma forma curiosa de "atender" ao público, não acha? 4. **Ataques sofisticados**: O que dizer dos ataques que envolvem técnicas de engenharia social ou exploração de vulnerabilidades? Ah, esses não se preocupam com o proxy. O atacante pode simplesmente contornar as medidas de proteção com uma boa dose de criatividade. 5. **Dependência do provedor**: Ao confiar exclusivamente em um serviço como a Cloudflare, você pode acabar colocando todos os ovos na mesma cesta. Se houver uma falha no serviço ou uma mudança de política, é bom estar preparado para um bocado de dor de cabeça. Enquanto a Cloudflare é uma excelente camada de proteção, tratá-la como a solução definitiva pode ser um caminho perigoso. Em segurança, sempre é bom ter um plano de defesa em profundidade, porque a verdade é que, em tecnologia, *sempre há algo mais que pode dar errado*! 😉
Pilationtem
Realmente, Cloudflare não é bala de prata, mas é necessário atualmente. > Até que vem o primeiro ataque Layer 7 bem elaborado E pode ter certeza que se você recebeu um ataque bem elaborado, que passa pela proteção básica de um firewall como a cloudflare não é por um "hackerzinho de porão" como você mencionou acima. Um ataque efetivo desses é caro, e é feito por alguém que se beneficia com o seu serviço estando off.
guilhermeDanielontem

ta. mas pra que serve guardar o ip de uma rede de bots? não serve de nada.

oxygenfrontontem
Vamos lá... - Análise forense: Os dados podem ajudar a identificar padrões de ataque e a origem dos bots, permitindo melhorar a segurança. - Mitigação futura: Com as informações dos IPs envolvidos, é possível implementar regras de firewall ou outras medidas de bloqueio para prevenir futuros ataques. - Cooperação com ISPs: Os IPs podem ser compartilhados com provedores de internet para que possam investigar e desativar os bots, ajudando a neutralizar a rede. - Prevenção de ataques direcionados: Conhecer as IPs que participaram de um ataque pode ajudar a entender e prevenir ataques mais complexos ou direcionados no futuro. Além disso, criar sessões (sem login) para acompanhar quem acessa seu sistema e talvez levantar "correlação entre atividade legítima e ataques de negação de serviço distribuídos (DDoS)" Existem várias razões. É relativamente comum que quem realiza um ataque DDoS tente acessar o site durante ou após o ataque para verificar se o site está fora do ar. Nesse momento, posso ter tudo auditado, saca??