tcpdump

Il DNS è un protocollo che nasce in un’epoca storica in cui la priorità era quella di riuscire a realizzare una rete funzionante di dispositivi interconnessi tra loro, durante cui la componente di sicurezza non era neanche presa in considerazione. Quasi tutte le organizzazioni hanno un DNS pubblico, curato e protetto perché esposto a Internet, e un DNS interno che vive tranquillo nella rete corporate, spesso dato per sicuro per definizione, senza applicarvi lo stesso livello di manutenzione e di attenzione. Tuttavia, il DNS interno è fondamentale allo stesso modo, poiché permette a tutti i servizi interni all’organizzazione di funzionare correttamente: autenticazioni, applicazioni, microservizi, integrazioni legacy, cloud ibrido. Se qualcuno dovesse riuscire a manipolarlo modificando le risoluzioni a proprio piacimento, gli utenti verrebbero indirizzati verso servizi fasulli senza neanche possibilità di accorgersene. A quel punto, basterebbe clonare i form di autenticazione dei servizi Microsoft, Google o di una banca, e le credenziali potrebbero finire in mano agli attaccanti con grande semplicità. Negli anni, la comunità informatica si è mossa per aggiungere un layer di sicurezza al DNS, che, tuttavia, si basa su primitive crittografiche asimmetriche. Tuttavia, l’avvento del calcolo quantistico potrebbe ridefinire il concetto stesso di robustezza crittografica e, quindi, comprendere questi meccanismi crittografici e il ruolo dell’entropia, è il primo passo per progettare un DNS resiliente nel futuro post-quantum. In questo articolo portiamo il fenomeno in laboratorio, controllando le variabili, riducendo l’entropia, analizzando il comportamento del resolver; tutto per comprendere in modo quantitativo perché le contromisure moderne di randomizzazione, 0x20 encoding, DNSSEC hanno innalzato drasticamente il costo computazionale dell’attacco. Cosa è il DNS Cache Poisoning Il DNS cache poisoning nasce principalmente da scelte progettuali che avevano senso nel loro contesto storico. Il DNS degli anni ’80 era costruito sulla fiducia reciproca tra i nodi della rete, non sull’autenticazione crittografica: una scelta ragionevole per l’epoca, che però ha lasciato in eredità un compromesso strutturale tra performance e verificabilità che ancora oggi non è stato risolto, perché il caching rimane necessario al funzionamento dell’infrastruttura globale. Un resolver — che sia quello di un ISP, di Cloudflare o di una rete aziendale — memorizza localmente le risposte DNS per ridurre la latenza. Se un attaccante riesce a inserire un record falso prima che arrivi la risposta legittima, quella voce modificata rimane in cache per tutta la durata del TTL, potenzialmente per ore, senza che esistano meccanismi autonomi in grado di rilevarlo. Vale la pena chiarire che il TTL non è un parametro di sicurezza, ma di efficienza: abbreviarlo riduce la finestra di esposizione, ma non impedisce l’attacco. Portare a termine un attacco di questo tipo richiede visibilità sulla rete, un timing preciso, o una posizione privilegiata nel percorso del traffico. Non è banale, ma è alla portata di una gamma piuttosto ampia di attori: insider compromessi, provider infetti, attaccanti con accesso a livello di autonomous system. DNSSEC viene proposto proprio per affrontare questo problema, introducendo firme crittografiche che renderebbero il cache poisoning inefficace. Eppure è adottato su una percentuale ancora molto bassa dei domini .com, stimata tra il 5 e il 10%. Le ragioni sono quelle classiche dei problemi di azione collettiva: il costo di gestione delle chiavi, la complessità operativa e l’assenza di un incentivo economico concreto pesano più del beneficio percepito, in mancanza di un coordinamento globale che renda l’adozione conveniente per tutti. Mitigazioni (non definitive): DNS-over-HTTPS/TLS: Protegge il trasporto, non la validazione del contenuto. Efficace, economico, in adozione crescente. Rate limiting e anomaly detection: Riducono il rischio di brute-force, insufficienti da sole. Network segmentation: Parte di una defense-in-depth, non risolutiva. Come si avvelena una cache DNS Il DNS utilizza UDP, ovvero un protocollo che non stabilisce connession, non esegue handshake, non mantiene stato. Il resolver esegue una query e rimane in attesa di una risposta. Il bias architetturale di fondo non stava nell’ignorare la sicurezza, ma nel subordinarla consapevolmente alla performance e alla semplicità operativa. In una rete accademica di dimensioni contenute, il rischio di iniezione malevola sembrava trascurabile rispetto al costo di implementare un’autenticazione robusta. Una scelta che aveva una sua logica, e che oggi presenta un conto difficile da saldare. La meccanica dell’attacco L’attacco sfrutta una finestra temporale: quando il resolver non trova una risposta in cache, invia una query UDP e resta in ascolto. In quel lasso di tempo, un attaccante può fare tre cose. Prima, stimolare la query richiedendo la risoluzione di un dominio non ancora cachato. Poi, inondare il resolver di risposte falsificate, spacciandosi per il nameserver autoritativo, prima che arrivi quella legittima. Infine, passare il controllo di validazione: se la risposta falsa contiene il query ID corretto, il resolver la accetta senza ulteriori verifiche. Questo meccanismo poggia su due assunzioni sbagliate. La prima è che il query ID funzioni come strumento di autenticazione, mentre in realtà è solo un identificatore di transazione. Con soli 16 bit, i valori possibili sono 65.536: abbastanza pochi da rendere il brute force praticabile a velocità sufficiente. La seconda assunzione è che l’ampiezza dello spazio di ricerca renda il timing irrilevante. Non è così: un attaccante non deve indovinare a caso, può semplicemente inondare il resolver con tutte le combinazioni di ID in pochi millisecondi. Kaminsky, 2008 Nel 2008, Dan Kaminsky mostrò come moltiplicare le finestre di attacco sfruttando sottodomini casuali. Invece di puntare a un singolo record, l’attaccante genera query verso sottodomini inesistenti — random1.example.com, random2.example.com — ognuna delle quali apre una nuova finestra con un nuovo query ID da indovinare. Le conseguenze di quella scoperta vanno lette con attenzione. La vulnerabilità non era ignota: era teoricamente possibile fin dal design originale, ma era stata considerata impraticabile su larga scala. La divulgazione responsabile di Kaminsky portò a patch simultanee da parte di tutti i vendor principali in un singolo giorno, un evento eccezionale nel panorama della sicurezza. Tuttavia quella risposta coordinata non risolse il problema, lo contenne. Le contromisure adottate — randomizzazione della porta sorgente, randomizzazione dell’ID, validazione dell’indirizzo sorgente — rendono l’attacco brute-force più costoso, ma non toccano il vettore di fondo: l’iniezione di risposte non autorizzate rimane possibile. Quello che Kaminsky non ha risolto Il problema architetturale è rimasto intatto. UDP non ha alcun meccanismo di autenticazione intrinseca, e un attaccante con visibilità sulla rete — all’interno di una rete locale, attraverso un ISP compromesso, o con un posizionamento BGP favorevole — può ancora intercettare la query originale, conoscere il query ID senza doverlo indovinare, e inviare una risposta falsificata con un timing molto più preciso. Può anche aggirare la randomizzazione della porta semplicemente inviando risposte su porte multiple. Le patch del 2008 hanno alzato il costo dell’attacco e spostato la soglia verso attori con capacità tecniche maggiori. Ma nella narrazione comune questo dettaglio tende a sparire, lasciando l’impressione che il problema sia stato risolto, quando invece è stato solo reso più selettivo. LAB in a Cache Disclaimer: Tutti gli scenari descritti in questo articolo devono essere riprodotti ESCLUSIVAMENTE in ambienti isolati, di laboratorio, su sistemi di cui si è proprietari o per cui si ha esplicita autorizzazione scritta. L’autore declina ogni responsabilità per uso improprio. Nel corso di questo laboratorio pratico abbiamo riprodotto un attacco di DNS Cache Poisoning in ambiente controllato. Non si è trattato di una simulazione teorica: ogni fase è stata eseguita concretamente, con strumenti reali, su un’infrastruttura appositamente configurata. L’obiettivo non era semplicemente dimostrare che l’attacco funziona, ma evidenziare come certe configurazioni, spesso date per scontate o ritenute sufficientemente robuste, possano diventare il punto di cedimento di un’intera infrastruttura DNS. Nella pratica quotidiana si tende a concentrare l’attenzione sulle minacce più visibili come malware, phishing e vulnerabilità applicative, lasciando in secondo piano i protocolli fondamentali su cui tutto il resto si appoggia, tra cui il DNS. Per rendere il laboratorio riproducibile e focalizzato sul meccanismo dell’attacco, sono state introdotte alcune assunzioni operative con l’obiettivo preciso di isolare le variabili rilevanti e ridurre i tempi di esecuzione. Queste semplificazioni non alterano la validità del modello di attacco, ma ne riproducono fedelmente la logica e permettono di osservarne il funzionamento senza che il rumore ambientale oscuri ciò che conta davvero. Le assunzioni adottate sono le seguenti: Porta DNS fissa. In un ambiente di produzione reale, i resolver moderni adottano la randomizzazione della porta sorgente come contromisura contro il bruteforce del transaction ID. In questo laboratorio la porta è stata fissata staticamente, eliminando questa variabile abiamo abbassato l’entropia riducendo lo spazio di ricerca dell’attacco a soli 65.536 valori il query ID a 16 bit. Questa scelta riflette scenari reali in cui la randomizzazione è assente o mal implementata, condizione tutt’altro che rara su apparati embedded, resolver legacy o configurazioni non aggiornate. Ambiente Docker isolato. L’intera infrastruttura del laboratorio è stata containerizzata tramite Docker. Questo ha permesso di mantenere un ambiente riproducibile, pulito e isolato dal resto della rete, garantendo che ogni esecuzione partisse dalle stesse condizioni iniziali senza interferenze esterne. Server autoritativo in intranet container. Anziché coinvolgere nameserver autoritativi reali su Internet, è stato deployato un server autoritativo all’interno della stessa rete interna dei container. Questo ha eliminato la latenza di rete variabile come fattore di disturbo, rendendo osservabile con precisione la finestra temporale critica in cui l’attaccante deve inserire la risposta falsificata prima di quella legittima. Environment L’infrastruttura del laboratorio è interamente basata su Docker e si compone di quattro container, ciascuno con un ruolo specifico e ben definito all’interno dello scenario di attacco. dns-victim è il resolver DNS bersaglio dell’attacco. Riceve le query dal client, le risolve interrogando il server autoritativo e mantiene la cache locale. È il nodo che vogliamo avvelenare: una volta che una risposta falsificata viene accettata e memorizzata nella sua cache, qualsiasi client che si affidi a lui riceverà l’indirizzo IP malevolo per tutta la durata del TTL. dns-upstream rappresenta il server autoritativo, ovvero la fonte di verità per la risoluzione dei domini nel nostro scenario. In un contesto reale sarebbe raggiungibile su Internet; in questo laboratorio è confinato all’interno della rete interna dei container, eliminando la variabilità della latenza esterna e rendendo la finestra temporale di attacco misurabile con precisione. dns-attacker è il nodo da cui viene condotto l’attacco. Il suo obiettivo è intercettare il momento in cui il resolver vittima effettua una query verso il server autoritativo e iniettare una risposta DNS falsificata prima che quella legittima venga recapitata, sfruttando la porta fissa enumerando esaustivamente il query ID. client rappresenta l’utente finale. Il suo ruolo è duplice: da un lato genera il traffico DNS che innesca la catena di risoluzione, dall’altro è lo strumento di verifica è attraverso le sue query che osserviamo se l’avvelenamento della cache ha avuto successo e se il resolver sta restituendo l’indirizzo IP malevolo al posto di quello legittimo. Struttura del Laboratorio Il laboratorio si articola in due fasi distinte e complementari, progettate per offrire una visione completa del problema prima dal lato offensivo, poi da quello difensivo. Fase 1 — Exploitation. Viene condotto l’attacco di DNS Cache Poisoning nella sua forma concreta. Partendo dall’ambiente descritto, si dimostra passo per passo come un attaccante riesca ad avvelenare la cache del resolver dns-victim, inducendolo ad accettare e memorizzare una risposta DNS falsificata. L’evidenza del poisoning viene raccolta direttamente osservando il contenuto della cache e il comportamento del client, che inizia a ricevere indirizzi IP malevoli in risposta a query legittime. Fase 2 — Mitigazione con DNSSEC. Una volta documentato l’attacco, l’infrastruttura viene riconfigurata abilitando DNSSEC sul resolver e sul server autoritativo. DNSSEC introduce la firma crittografica dei record DNS: ogni risposta è accompagnata da una firma digitale verificabile, legata a una chiave crittografica che l’attaccante non conosce e non può replicare. In questo scenario, conoscere il transaction ID della query non è più sufficiente una risposta falsificata, priva di firma valida, viene rigettata dal resolver indipendentemente dalla velocità di invio o dalla correttezza del TXID. L’attacco fallisce in modo netto e misurabile, rendendo evidente il salto di sicurezza che DNSSEC introduce rispetto alla configurazione di default. Prima Fase Setup dell’Environment L’intero environment viene orchestrato tramite Docker Compose. All’interno della directory del progetto è presente un file docker-compose.yml che definisce i quattro container dns-victim, dns-upstream, attacker e client, la loro configurazione di rete interna e le dipendenze reciproche. Qui la configurazione del file docker-compose.yaml: Visualizza configurazione Docker del lab DNS ``yamlversion: '3.8'services: # --- VITTIMA (Il server da avvelenare) --- dns-victim: image: ubuntu/bind9:latest container_name: dns-victim networks: poison-net: ipv4_address: 172.25.0.10 volumes: - ./config/victim:/etc/bind command: ["/usr/sbin/named", "-g", "-c", "/etc/bind/named.conf", "-u", "bind"] # --- UPSTREAM (L'autorità reale, ma LENTA) --- dns-upstream: image: ubuntu/bind9:latest container_name: dns-upstream networks: poison-net: ipv4_address: 172.25.0.20 volumes: - ./config/upstream:/etc/bind cap_add: - NET_ADMIN # Necessario per rallentare la rete con tc # All'avvio configuriamo Bind e aggiungiamo 1 secondo di ritardo alla rete command: > /bin/sh -c "apt-get update && apt-get install -y iproute2 && tc qdisc add dev eth0 root netem delay 1000ms && /usr/sbin/named -g -c /etc/bind/named.conf -u bind" # --- ATTACKER --- attacker: image: kalilinux/kali-rolling container_name: dns-attacker networks: poison-net: ipv4_address: 172.25.0.66 tty: true cap_add: - NET_ADMIN command: /bin/sh -c "apt-get update && apt-get install -y python3-scapy dnsutils net-tools nano && /bin/bash" # --- CLIENT (L'utente ignaro) --- client: image: infoblox/dnstools:latest container_name: client networks: poison-net: ipv4_address: 172.25.0.100 dns: - 172.25.0.10 # Punta alla vittima come DNS principale tty: true stdin_open: true #command: /bin/sh -c "apk add --no-cache bind-tools && tail -f /dev/null"networks: poison-net: driver: bridge ipam: config: - subnet: 172.25.0.0/24 `` Qui i files di configurazione del Server Victim: named.conf: options { directory "/var/cache/bind"; recursion yes; allow-query { any; }; dnssec-validation yes;# DISABILITA DNSSEC # LA CHIAVE DEL SUCCESSO NEL LAB: # Fissiamo la porta da cui la vittima invia le richieste all'upstream. # Senza questo, dovresti indovinare porta (1-65535) E transaction ID (1-65535). query-source address * port 33333; # Inoltra tutto all'upstream locale (niente internet reale) forwarders { 172.25.0.20; }; forward only;}; Qui i files di configurazione del Server DNS Autoritativo: named.conf: include "/etc/bind/named.conf.options";zone "bank.intranet" { type master; file "/etc/bind/db.bank"; # Attiva la firma automatica key-directory "/etc/bind"; inline-signing yes; allow-query { any; }; # @ IN A 1.1.1.1bank IN A 1.1.1.1 Generazione delle chiavi DNSSEC Genera la Zone Signing Key (ZSK)dnssec-keygen -a RSASHA256 -b 2048 -n ZONE bank.intranet# Genera la Key Signing Key (KSK) — chiave di ancoraggio della fiduciadnssec-keygen -a RSASHA256 -b 4096 -f KSK -n ZONE bank.intranet Vengono generati quattro file: Kbank.intranet.+008+ .key # ZSK pubblica Kbank.intranet.+008+ .private # ZSK privata Kbank.intranet.+008+ .key # KSK pubblica Kbank.intranet.+008+ .private # KSK privata Inclusione delle chiavi nel zone file Aggiungere in fondo al file db.bank.intranet: $INCLUDE /etc/bind/zones/Kbank.intranet.+008+ .key$INCLUDE /etc/bind/zones/Kbank.intranet.+008+ .key Firma della zona dnssec-signzone -A -3 $(head -c 1000 /dev/random | sha1sum | cut -b 1-16) \ -N INCREMENT \ -o bank.intranet \ -t /etc/bind/zones/db.bank.intranet Questo genera il file firmato db.bank.intranet.signed. Aggiornare named.conf per puntare al file firmato: zone "bank.intranet" { type master; file "/etc/bind/zones/db.bank.intranet.signed"; allow-transfer { none; };}; Server Locale — dns-victim named.conf options { directory "/var/cache/bind"; recursion yes; # resolver ricorsivo allow-query { any; }; allow-recursion { any; }; dnssec-validation yes; # abilita validazione DNSSEC dnssec-enable yes; # Trust anchor: punta al server autoritativo interno forwarders { ; }; forward only;};# Trust anchor manuale per bank.intranet# (sostituisce il ruolo della root chain of trust in ambiente intranet)trusted-keys { "bank.intranet." 257 3 8 " ";}; A questo punto siamo pronti per rilanciare l’attacco, quello che ci aspettiamo è che una volta indovinato il TXID della query il server DNS Victim risponderà ServFail. Come prevenire il DNS Cache Poisoning La difesa contro il DNS Cache Poisoning non si esaurisce in una singola contromisura, ma richiede un approccio stratificato che agisce su più livelli dell’infrastruttura. Adottare DNSSEC. È la contromisura strutturale per eccellenza. DNSSEC introduce la firma crittografica dei record DNS tramite crittografia a chiave pubblica, permettendo al resolver di verificare che la risposta ricevuta provenga effettivamente dal server autoritativo legittimo e non sia stata alterata in transito. Un attaccante che non possiede la chiave crittografica non può forgiare una risposta valida indipendentemente dalla velocità di invio o dalla correttezza del transaction ID. Mantenere aggiornato il software DNS. Stabilire una cadenza regolare di aggiornamento e patching delle applicazioni DNS riduce concretamente la superficie di attacco, limitando la possibilità che un attaccante sfrutti vulnerabilità note o zero-day sui resolver in produzione. Cifrare il traffico DNS con DoH. DNS over HTTPS incapsula le query DNS all’interno di sessioni HTTPS cifrate, sottraendole all’osservazione e alla manipolazione in transito. Questo rende significativamente più difficile per un attaccante on-path intercettare query ID e porte sorgente le informazioni su cui si basa l’attacco di poisoning. Applicare un approccio Zero Trust alla configurazione DNS. I principi del modello Zero Trust impongono che nessun utente, dispositivo o richiesta venga considerato affidabile per default tutto deve essere autenticato e validato continuamente. Il DNS è un punto di controllo naturale in questa architettura: ogni indirizzo risolto può essere analizzato e confrontato con indicatori di compromissione, rendendo il resolver un sensore attivo nella catena di difesa. Scegliere un resolver veloce e resistente agli attacchi DoS. Il DNS Cache Poisoning sfrutta la finestra temporale tra la query del resolver e la risposta legittima un resolver rapido riduce questa finestra, abbassando le probabilità di successo dell’attacco. È altrettanto importante che il resolver scelto implementi nativamente controlli anti-poisoning e che il provider abbia la capacità infrastrutturale di assorbire attacchi DDoS volumetrici, che spesso accompagnano o preparano un tentativo di avvelenamento della cache. Conclusione Il DNS cache poisoning nasce come attacco probabilistico, reso possibile da una bassa entropia nelle richieste. La randomizzazione della porta sorgente ha innalzato drasticamente il costo computazionale dell’attacco, rendendolo di fatto impraticabile in scenari moderni. Con DNSSEC, il problema viene ulteriormente superato: la validità di una risposta non dipende più dall’indovinare un valore, ma dalla verifica crittografica della sua autenticità. In questo contesto, l’avvento del quantum computing non riabilita gli attacchi classici di cache poisoning, che rimangono limitati da vincoli di rete e da finestre temporali estremamente ristrette. Tuttavia, il tema quantistico riapre una riflessione diversa e più profonda: la robustezza a lungo termine degli algoritmi crittografici utilizzati da DNSSEC. Le firme basate su RSA ed ECDSA, pur sicure oggi, rientrano nel perimetro teorico degli algoritmi vulnerabili a un avversario quantistico sufficientemente maturo. Questo sposta il focus della sicurezza DNS dal “se l’attacco è possibile” al “quanto è sostenibile nel tempo il modello di fiducia adottato”. La vera sfida futura non sarà il ritorno del cache poisoning, ma l’adozione progressiva di meccanismi DNSSEC compatibili con la crittografia post‑quantum, in linea con le evoluzioni già in corso nel mondo TLS e PKI.

Cybersecurity jobs available right now: October 28, 2025 Analyst, Cybersecurity Threat Intelligence Brookfield Renewable | Canada | On-site – No longer accepting applications As a Cybersecurity Threat Intelligence Analyst, you will run monthly vulnerability scans across IT and OT environments, track remediation progress, and report results. You will collect and analyze phishing and security awareness metrics, conduct threat intelligence research using tools like Dark Owl, OpenCTI, and Shodan, and produce actionable reports. You will analyze incidents, document lessons learned, and manage key cybersecurity and technology risk systems. Application Security Engineer Binance | UAE | Remote – No longer accepting applications As an Application Security Engineer, you will strengthen and maintain the security posture of Binance’s DeFi and Web3 affiliates. You will respond to security issues from penetration tests, bug bounties, and assessments, analyze findings, and implement code-level fixes. You will collaborate on system architecture to improve security, integrate blockchain security solutions, and leverage AI tools to automate security detection throughout the SDLC and CI pipelines. BISO Barclays Investment Bank | Ireland | Hybrid – No longer accepting applications As a BISO, you will conduct risk assessments to identify and prioritize cybersecurity threats affecting the bank’s operations and data, guide mitigation strategies, and communicate findings to senior stakeholders. You will collaborate with business units to develop and implement security policies aligned with the bank’s risk management framework. You will also manage the implementation, testing, and monitoring of security controls to ensure their effectiveness and reduce risk. Get weekly updates on new cybersecurity job openings. Subscribe here! Cloud Security Engineer Deltatre | Italy | Hybrid – No longer accepting applications As a Cloud Security Engineer, you will define and enforce cloud security best practices, including IAM governance, secure configurations, and logging standards. You will implement security controls within Kubernetes environments, automate compliance and guardrails using CNAPP, and support incident response, forensics, threat analysis, and penetration test follow-ups to strengthen cloud security operations. Cybersecurity, Critical Infrastructure and Artificial Intelligence Regulation Principal Inspector Commission for Railway Regulation | Ireland | Hybrid – No longer accepting applications As a Cybersecurity, Critical Infrastructure and Artificial Intelligence Regulation Principal Inspector, you will establish and develop a new division overseeing entities in the rail transport sector under CER, NIS2, and AIA regulations. You will lead supervision and oversight activities, develop policies and procedures for the division, and ensure the Commission has the necessary technical expertise in network systems, resilience, and AI. You will also manage staff by setting goals, reviewing performance, and overseeing training and development. Cybersecurity Risk Officer Rockwell Land Corporation | Philippines | On-site – No longer accepting applications As an Cybersecurity Risk Officer, you will implement and maintain risk management frameworks and policies. You will perform vulnerability scans, penetration tests, and risk assessments while maintaining the risk register and tracking remediation. You will manage risk acceptance processes, monitor third-party compliance with standards like ISO 27001 and SOC 2, and ensure cybersecurity controls align with BC/DR plans. Cyber Security Engineer Skai | Israel | Hybrid – No longer accepting applications As a Cyber Security Engineer, you will develop and maintain automation scripts in Python to enhance SOC efficiency and incident response workflows. Perform initial triage and assessment of security incidents, identifying threats and recommending mitigation strategies. Conduct static and dynamic analysis to uncover malicious behaviours, code, and techniques. Apply forensic methodologies to extract, analyze, and interpret digital evidence to support investigations and attribution. Cyber Security Engineer Symbos CX | Philippines | Hybrid – No longer accepting applications As a Cyber Security Engineer, you will design and deploy security technologies such as firewalls, IDS/IPS, endpoint protection, and SIEM systems, integrating them across cloud and on-premises environments. You will perform regular security assessments, coordinate remediation efforts, and continuously monitor networks and systems to detect and respond to threats. You will also investigate incidents, conduct root cause analyses, and implement corrective actions to reduce risk. Cyber Security Expert Boerse Stuttgart Digital | Germany | Hybrid – No longer accepting applications As a Cyber Security Expert, you will assess, improve, and monitor cybersecurity infrastructure and architecture. Detect, analyze, and mitigate cyber threats and vulnerabilities. Secure cloud environments and integrate security into DevSecOps pipelines. Conduct risk assessments, threat modeling, and prioritize mitigation measures. Cyber Security Senior Analyst – Pentesting Societe Generale Global Solution Centre | India | Hybrid – No longer accepting applications As a Cyber Security Senior Analyst – Pentesting, you will support daily security operations while working independently and with team members. You will lead a specific function or process, mentor team members, and solve complex technical problems. You will assist in improving processes, provide regular functional updates to management, and help prioritize and deliver on team objectives. Cyber Security Senior Specialist SYNLAB International | Germany | Hybrid – No longer accepting applications As a Cyber Security Senior Specialist, you will lead incident response efforts, including rapid assessment, containment, and recovery. You will oversee real-time security monitoring, perform threat detection and hunting, and analyze threat intelligence to strengthen defenses. You will also enhance product security by designing, testing, and implementing robust protective measures. DevSecOps Engineer MSC Mediterranean Shipping Company | Italy | On-site – No longer accepting applications As a DevSecOps Engineer, you will assess team security postures, provide guidance, and track improvements. You will implement and manage automated security tools like SCA and SAST, design and maintain CI/CD pipelines, and support applications and cloud environments. You will collaborate with development, operations, and security teams and help resolve issues identified through penetration testing. Director of Security Hatch | Australia | Hybrid – View job details As a Director of Security, you will define, own and execute the company’s security strategy and roadmap, aligned with GFG’s security strategy and overall business objectives. Lead incident response playbooks, coordinate post-incident reviews, and implement improvements to minimise impact and protect assets. Conduct risk assessments and vulnerability management to reduce risk exposure through timely identification and mitigation. Director of Information Security Pattern Energy | USA | Hybrid – No longer accepting applications As a Director of Information Security, you will be responsible for establishing, leading, and maintaining the organization’s cybersecurity and information security programs to ensure alignment with business objectives, regulatory compliance, and security best practices. IAM and DLP Security Specialist SKF Group | France | On-site – No longer accepting applications As an IAM and DLP Security Specialist, you will design and manage IAM policies, oversee identity lifecycle processes, and implement role-based access controls. You will develop and enforce DLP policies, deploy enterprise-wide DLP solutions, and monitor alerts to prevent data loss. You will collaborate with stakeholders to classify data, ensure compliance with regulations such as GDPR and ISO 27001, and support audits through proper documentation and reporting. Information Security Auditor Thredd | United Kingdom | Hybrid – No longer accepting applications As an Information Security Auditor, you will conduct risk assessments to identify and mitigate risks in governance, data security, and compliance. You will respond to third-party information requests, ensuring alignment with regulatory and contractual requirements. You will audit security controls and systems for compliance with standards such as ISO 27001, SOC 2, and PCI DSS. You will also assess governance frameworks, recommend improvements, and monitor adherence to ensure ongoing compliance. Information Security Manager Solicitors Regulation Authority | United Kingdom | Hybrid – No longer accepting applications As an Information Security Manager, you will be a subject matter expert, providing strategic advice and operational support to ensure robust information security practices are embedded across the organisation. You’ll work closely with IT Security, Risk, and Governance colleagues to assess and manage risks, investigate incidents, and deliver assurance activities. You’ll also lead internal audits, maintain compliance with PCI DSS, and manage external certification processes. Manager – Forensics & Incident Response Emirates NBD | UAE | On-site – No longer accepting applications As a Manager – Forensics & Incident Response, you will ensure effective threat analysis and coordinated remediation efforts. You will integrate incident learnings into SOC operations for proactive threat mitigation, manage and refine incident response processes, and maintain strong cyber hygiene to achieve the unit’s goals. Manager, Security Engineering Headway | USA | Remote – No longer accepting applications As a Manager, Security Engineering, you will lead application and product security efforts at scale. You’ll develop security features, tools, and programs that help teams ship secure code and protect sensitive data across the software lifecycle. You’ll also build and grow your team through strategic planning, hiring, development, and leading high-impact initiatives. Manager Cyber Security Operations Sydney Trains | Australia | Hybrid – No longer accepting applications As a Manager of Cyber Security Operations, you will oversee operational security monitoring tools and implement security procedures for OT and ICS. You will lead a high-performing team responsible for cybersecurity monitoring, incident management, vulnerability and threat management, vendor and contract management, and policy and compliance. Program Cybersecurity Manager Alstom | France | On-site – No longer accepting applications As a Program Cybersecurity Manager, you will conduct system-level risk analyses to define security measures for design and deployment. You will specify subsystem security requirements, contribute to tender responses by outlining cybersecurity strategies, and support project teams in system implementation. Security Triage Analyst II Snowflake | USA | Remote – No longer accepting applications As a Security Triage Analyst II, you will triage alerts for insider threats, product security issues, and other security events. You will assess incident scope and impact within SLAs, escalate validated threats or take remediation actions, follow incident response playbooks, and support major security incidents. Senior Cybersecurity Engineer – Offensive CAAT Pension Plan | Canada | Hybrid – No longer accepting applications As a Senior Cybersecurity Engineer – Offensive, you will lead offensive security testing for AI/ML pipelines, low code/no code platforms, and cloud environments, identifying and exploiting vulnerabilities to strengthen defenses. Integrate security into development processes, collaborating with teams to ensure secure coding and configuration, and proactively address risks in web, mobile, and API applications. Oversee incident response and threat management, leveraging SIEM tools and real-time intelligence to detect, contain, and remediate cyber threats. SOC Cyber Threat Hunter StratasCorp Technologies | USA | On-site – No longer accepting applications As a SOC Cyber Threat Hunter, you will monitor real-time alert, session, and packet capture data. You will use tools such as Wireshark, WinDump, TCPDump, and SIEM systems to detect threats on MSC networks. You will triage alerts, assess threat scope, correlate data, and analyze IDS/IPS activity. You will also update and reconfigure security devices with the latest signatures and techniques to detect and prevent emerging threats. Web2 & Mobile Security Researcher Certora | Israel | Hybrid – No longer accepting applications As a Web2 & Mobile Security Researcher, you will analyze web and mobile applications, perform code reviews to find vulnerabilities, and assess interactions with Web3 infrastructures, wallets, SDKs, and smart contracts. You will produce research, create proof-of-concepts, and work with developers to ensure secure design and implementation.

When you need to analyze some suspicious pieces of code, it's interesting to detonate them in a sandbox. If you don't have a complete sandbox environment available or you just want to avoid generatin noise on your network, why not route the traffic to a sinkhole or NULL-route (read: packets won't be sent across the normal network and default gateway). When you inspect a process using the /proc[1] virtual filesystem, there is a "route" file: remnux@remnux:~$ cat /proc/1180/net/route Iface Destination Gateway Flags RefCnt Use Metric Mask MTU Window IRTT ens19 00000000 01FEA8C0 0003 0 0 100 00000000 0 0 0 ens18 004A10AC 00000000 0001 0 0 0 00FFFFFF 0 0 0 ens19 00FEA8C0 00000000 0001 0 0 0 00FFFFFF 0 0 0 ens19 01FEA8C0 00000000 0005 0 0 100 FFFFFFFF 0 0 0 It displays the IP routing table assigned to this process. Typically, IP addresses are encoded in little-endian hexadecimal values. They can be easily decoded using a few lines of Python: gw = "01FEA8C0" octets = [gw[i:i+2] for i in range(0, len(gw), 2)] ip = '.'.join(str(int(o, 16)) for o in octets) print(ip) # Will return: 1.254.168.192 Does it mean that we could apply a specific routing table to a process? Yes and no... In /proc, the "route" file is read-only. But, Linux is full of features that many people aren't aware of. One of them are namespaces[2]. It's a kernel feature (introduced around 2016 if I remember well) that provides isolation of system resources between processes (a bit like containers). Each namespace type—such as PID, mount, UTS, network, IPC, and user—isolates a specific aspect of the operating system environment. For example, the network namespace gives processes their own network stack, including interfaces and routing tables. Very interesting! Let's try this and run our suscipious script in a dedicated namespace. My suspicious script will be super simple: remnux@remnux:~$ cat sample.sh #!/bin/bash echo "Am I bad?" curl https://isc.sans.edu First example, no network connectivity at all! remnux@remnux:~$ sudo unshare --net bash root@remnux:/home/remnux# ./sample.sh Am I bad? curl: (6) Could not resolve host: isc.sans.edu root@remnux:/home/remnux# ip a 1: lo: mtu 65536 qdisc noop state DOWN group default qlen 1000 link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 root@remnux:/home/remnux# ip r Error: ipv4: FIB table does not exist. Dump terminated root@remnux:/home/remnux# exit remnux@remnux:~$ The unshare command (executed as root) will create a new shell in a new namespace with dropped network settings. When curl is executed, it can't resolve isc.sans.edu nor connect to it. We have a complete network isolation. Second example, let's build a dedicated IP stack that will route packets to another IP address, our synchole. A pair of virtial Ethernet interfaces must be added. In this case, 10.0.0.1 will be the new namespace and 10.0.0.2 the main one. (Note: I'll change the bash prompt to make it clearer) remnux@remnux:~$ sudo unshare --net bash root@remnux:/home/remnux# export PS1="namespace> " namespace> ip link set lo up namespace> ip link add veth0 type veth peer name veth1 namespace> ip link set veth0 up namespace> ip addr add 10.0.0.1/24 dev veth0 namespace> ip a 1: lo: mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000 link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 inet 127.0.0.1/8 scope host lo valid_lft forever preferred_lft forever inet6 ::1/128 scope host valid_lft forever preferred_lft forever 2: veth1@veth0: mtu 1500 qdisc noop state DOWN group default qlen 1000 link/ether b6:5c:6e:ed:c3:62 brd ff:ff:ff:ff:ff:ff 3: veth0@veth1: mtu 1500 qdisc noqueue state LOWERLAYERDOWN group default qlen 1000 link/ether 66:72:35:1f:9f:9e brd ff:ff:ff:ff:ff:ff inet 10.0.0.1/24 scope global veth0 valid_lft forever preferred_lft forever namespace> ip link set veth1 netns 1 On the main namespace (your original shell), create the virtual NIC: root@remnux:/home/remnux# ip addr add 10.0.0.2/24 dev veth1 root@remnux:/home/remnux# ip link set veth1 up Back in the new namespace: namespace> ping 10.0.0.2 PING 10.0.0.2 (10.0.0.2) 56(84) bytes of data. 64 bytes from 10.0.0.2: icmp_seq=1 ttl=64 time=0.020 ms 64 bytes from 10.0.0.2: icmp_seq=2 ttl=64 time=0.034 ms ^C --- 10.0.0.2 ping statistics --- 2 packets transmitted, 2 received, 0% packet loss, time 1023ms rtt min/avg/max/mdev = 0.020/0.027/0.034/0.007 ms Let's add a default route to the IP in the main namespace: namespace> ip route add default via 10.0.0.2 namespace> ping 8.8.8.8 PING 8.8.8.8 (8.8.8.8) 56(84) bytes of data. ^C --- 8.8.8.8 ping statistics --- 13 packets transmitted, 0 received, 100% packet loss, time 12293ms If we run a tcpdump on veth1, we can now capture all the network connection attempts from the namespace: root@remnux:/home/remnux# tcpdump -i veth1 -n tcpdump: verbose output suppressed, use -v or -vv for full protocol decode listening on veth1, link-type EN10MB (Ethernet), capture size 262144 bytes 11:02:32.122380 ARP, Request who-has 10.0.0.2 tell 10.0.0.1, length 28 11:02:32.122408 ARP, Reply 10.0.0.2 is-at b6:5c:6e:ed:c3:62, length 28 11:02:32.154271 IP 10.0.0.1 > 8.8.8.8: ICMP echo request, id 18547, seq 6, length 64 11:02:33.178401 IP 10.0.0.1 > 8.8.8.8: ICMP echo request, id 18547, seq 7, length 64 11:02:34.202411 IP 10.0.0.1 > 8.8.8.8: ICMP echo request, id 18547, seq 8, length 64 ^C 5 packets captured 5 packets received by filter 0 packets dropped by kernel Finally, let's verify the routing table of the shell running in the new namespace: namespace> echo $$ 149522 On the main namespace: root@remnux:/home/remnux# cat /proc/149522/net/route Iface Destination Gateway Flags RefCnt Use Metric Mask MTU Window IRTT veth0 00000000 0200000A 0003 0 0 0 00000000 0 0 0 veth0 0000000A 00000000 0001 0 0 0 00FFFFFF 0 0 0 (0x0200000A = 10.0.0.2) Done! The current configuration is very basic and does not provide, amongst others, a DNS. Your sinkholed sample won't be able to resolve FQDN. Also, you could really route the packets by enabling ip_forward and NAT the traffic. WARNING: This is not a bullet-proof solution to perform malware analysis: Only the network traffic was isolated! [1] https://docs.kernel.org/filesystems/proc.html [2] https://en.wikipedia.org/wiki/Linux_namespaces Xavier Mertens (@xme) Xameco Senior ISC Handler - Freelance Cyber Security Consultant PGP Key