Páginas

quinta-feira, 2 de abril de 2026

🔥💀 “VOCÊ APRENDEU SEGURANÇA… MAS JÁ TESTOU SEU SISTEMA SOB ATAQUE?”

 

Bellacosa Mainframe teste seu sistema sob ataque

🔥💀 “VOCÊ APRENDEU SEGURANÇA… MAS JÁ TESTOU SEU SISTEMA SOB ATAQUE?”

10 atividades práticas para sair da teoria e começar a proteger sistemas de verdade


☕ INTRODUÇÃO — A VERDADE QUE DÓI

Segurança não se aprende lendo.
👉 Se aprende quebrando sistema… e depois corrigindo.

Se você não praticar:

💣 você só vai descobrir o problema… quando o atacante descobrir primeiro.


🧪 ATIVIDADE 1 — ENCONTRE UM SQL INJECTION NO SEU PRÓPRIO SISTEMA

🎯 Objetivo

Pensar como atacante


💻 Faça isso

  • Pegue um input (API, tela, CICS, batch input)
  • Teste:
' OR 1=1 --

💥 Resultado esperado

👉 Se algo estranho acontecer… você tem vulnerabilidade


🧠 Versão COBOL

  • validar WS-FIELD
  • nunca confiar em input externo

💬 Comentário

“Se você não testar… alguém vai testar por você.”


🧪 ATIVIDADE 2 — REMOVA TODOS OS HARDCODED SECRETS

🎯 Objetivo

Eliminar o erro mais comum do mundo


💻 Procure no seu código

password
token
key
secret

💥 Se encontrar:

👉 você tem risco crítico


✅ Solução

  • usar Vault / RACF
  • variáveis externas

💬 Easter egg

👉 80% dos vazamentos começam assim


🧪 ATIVIDADE 3 — RODE UM SCAN DE SEGURANÇA

🎯 Objetivo

Ver o que você não vê


💻 Ferramentas

  • Snyk
  • SonarQube

💥 Resultado

👉 lista de vulnerabilidades reais


💬 Comentário

“Scanner não cria problema… só revela.”


🧪 ATIVIDADE 4 — EXPLORE UM XSS NA PRÁTICA

🎯 Objetivo

Ver o ataque funcionando


💻 Teste

<script>alert('XSS')</script>

💥 Resultado

👉 se executar → vulnerável


🧠 Versão real

  • portais corporativos
  • front-end conectado ao mainframe

🧪 ATIVIDADE 5 — ATUALIZE UMA DEPENDÊNCIA VULNERÁVEL

🎯 Objetivo

Entender SCA na prática


💻 Faça

  • rode scan
  • escolha uma lib vulnerável
  • atualize

💥 Resultado

👉 CVE desaparece


💬 Comentário

“Seu código pode estar perfeito… sua lib não.”


🧪 ATIVIDADE 6 — QUEBRE SEU PRÓPRIO LOGIN

🎯 Objetivo

Pensar como invasor


💻 Teste

  • inputs inválidos
  • SQL injection
  • brute force simples

💥 Resultado

👉 encontrar bypass


💬 Comentário

“Se login falha… todo sistema falha.”


🧪 ATIVIDADE 7 — IMPLEMENTE HEADERS DE SEGURANÇA

🎯 Objetivo

Blindar camada web


💻 Adicionar

  • Content-Security-Policy
  • HSTS
  • X-Frame-Options

💥 Resultado

👉 reduz ataque XSS e clickjacking


🧪 ATIVIDADE 8 — CRIPTOGRAFE UM ARQUIVO SENSÍVEL

🎯 Objetivo

Proteger dados em repouso


💻 Use OpenSSL

openssl enc -aes-256-cbc -salt -pbkdf2 -iter 2500

💥 Resultado

👉 arquivo ilegível sem senha


💬 Comentário

“Dado sem criptografia é dado público.”


🧪 ATIVIDADE 9 — CRIE UM MINI PIPELINE DE SEGURANÇA

🎯 Objetivo

Automação


💻 Simule

commit → scan → resultado → bloqueio

💥 Resultado

👉 segurança contínua


🧠 Versão mainframe

  • Jenkins + JCL + scan

🧪 ATIVIDADE 10 — FAÇA UM “ATAQUE CONTROLADO”

🎯 Objetivo

Pensar como hacker


💻 Faça

  • use OWASP ZAP
  • ataque sua própria aplicação

💥 Resultado

👉 visão real de risco


💬 Comentário

“Sistema seguro é sistema testado sob ataque.”


🧠 CONCLUSÃO — O DIFERENCIAL REAL

Depois dessas 10 atividades, você não é mais:

👉 um dev que escreve código

Você é:

👉 alguém que entende como o sistema quebra… e como evitar isso


💬 FRASE FINAL

“Segurança não é o que você implementa…
é o que sobrevive quando alguém tenta quebrar.”

 

quarta-feira, 1 de abril de 2026

🔥💀 “SEU COBOL NÃO QUEBROU… FOI O SMP/E QUE MEXEU NOS BASTIDORES”

 

Bellacosa Mainframe comenta sobre cobol quebrando e a busca por culpados smp/e nos bastidores

🔥💀 “SEU COBOL NÃO QUEBROU… FOI O SMP/E QUE MEXEU NOS BASTIDORES”

O guia que todo dev COBOL deveria ler antes de culpar o programa


Se você é dev COBOL, já viveu isso:

💣 “o programa rodava ontem… hoje ABENDOU… e ninguém mexeu em nada”

👉 Spoiler: alguém mexeu sim
👉 E provavelmente foi o SMP/E


🧠 A VERDADE QUE NINGUÉM TE CONTA

No mundo do mainframe, seu COBOL não vive sozinho.

Ele depende de:

  • load modules
  • bibliotecas
  • runtime
  • serviços do sistema

E tudo isso é controlado por um cara invisível:

💀 SMP/E — o gerente silencioso do ambiente


🕰️ UM POUCO DE HISTÓRIA (QUE EXPLICA TUDO)

Antes dos anos 80…

  • sysprog fazia manutenção manual
  • copiava módulos na mão
  • sobrescrevia código sem controle

Resultado?

💣 ambiente inconsistente
💣 sistema instável
💣 caos

Então nasceu o SMP (depois SMP/E):

👉 pra trazer controle, rastreabilidade e sanidade


🔥 TRADUZINDO PRA VOCÊ, DEV COBOL

Pensa assim:

seu programa = ponta do iceberg
smp/e = quem controla o iceberg inteiro

⚙️ O QUE O SMP/E FAZ (NA VIDA REAL)

  • instala produtos (CICS, DB2, z/OS)
  • aplica correções (PTFs)
  • atualiza módulos que você usa
  • controla versões do ambiente

💡 Ou seja:

🔥 ele pode mudar seu runtime sem você tocar no código


💀 O FLUXO QUE DECIDE SEU DESTINO

receive → apply → accept

🧩 RECEIVE

👉 baixa a mudança
👉 não altera nada ainda


💥 APPLY

👉 altera o ambiente
👉 muda módulos que seu programa usa

💀 é aqui que seu COBOL pode “mudar de comportamento”


🏁 ACCEPT

👉 oficializa a mudança
👉 vira baseline


⚠️ EASTER EGG (VIDA REAL)

💣 “ninguém mexeu no programa”
👉 mas alguém fez APPLY ontem à noite


🧱 TARGET vs DLIB (A CHAVE DO UNIVERSO)

👉 Isso aqui explica MUITA coisa:

TipoO que é
TARGETo que roda
DLIBbase confiável

💡 Cenário clássico:

  • APPLY alterou TARGET
  • seu programa usa nova versão
  • comportamento mudou

👉 você nem viu acontecer


♻️ RESTORE — O HERÓI ESQUECIDO

Quando dá ruim:

👉 SMP/E pode restaurar versão da DLIB

restore = desfazer desastre

💡 Sim… dá pra “voltar no tempo”


🧠 CSI — O CÉREBRO DO SISTEMA

SMP/E não trabalha no escuro.

Ele mantém um banco chamado:

🔥 CSI (Consolidated Software Inventory)

Ali ele sabe:

  • o que está instalado
  • versões
  • dependências
  • histórico

💀 Sem CSI consistente:

você não tem ambiente… tem uma bomba relógio


📦 SYSMOD — O PACOTE QUE MUDA TUDO

Tudo que entra no sistema vem assim:

👉 SYSMOD

Tipos:

  • PTF → correção
  • APAR → problema corrigido
  • FUNCTION → nova funcionalidade
  • USERMOD → customização

💡 Curiosidade:

USERMOD mal feito = pesadelo eterno 😄


🧠 MCS — A LINGUAGEM SECRETA

Dentro do SYSMOD existe:

++ alguma coisa

Isso são MCS (instructions)

Exemplo:

++VER
++MOD
++HOLD

💡 Tradução:

SMP/E não “decide”… ele executa ordens do SYSMOD


💣 DEPENDÊNCIAS (ONDE O BICHO PEGA)

Tipos:

  • PRE → precisa antes
  • REQ → precisa junto
  • SUP → substitui

💥 Se faltar dependência:

APPLY FAILED

👉 e o sysprog entra em guerra


🧬 TRACKING — O NÍVEL NINJA

SMP/E sabe exatamente o nível de cada módulo:

FMID = origem
RMID = última substituição
UMID = updates

💡 Isso permite:

  • saber versão real
  • evitar conflito
  • diagnosticar erro

⚠️ EASTER EGG DE PRODUÇÃO

💣 “o bug apareceu do nada”

👉 não apareceu

👉 o RMID mudou 😄


🧠 VISÃO DE GUERRA (PRA DEV COBOL)

Se você entender SMP/E:

✅ você para de culpar o programa
✅ entende mudanças de ambiente
✅ conversa melhor com sysprog
✅ vira profissional diferenciado


🔥 UMA GRANDE VERDADE

💀 COBOL quebra raramente
💀 ambiente quebra frequentemente


🍛 A PENSAR NA HORA DO ALMOÇO

👉 Quantos erros você já debugou…

…que na verdade eram:

  • mudança de load module
  • alteração de runtime
  • PTF aplicada

🧪 MÃO NA MASSA (MENTALIDADE)

Próxima vez que algo quebrar:

❌ não pergunte:

“quem mudou o programa?”

✅ pergunte:

“teve APPLY recente?”


🚀 FRASE FINAL (ESTILO BELLACOSA)

🔥 “Seu programa não mudou…
o mundo ao redor dele mudou.”