Configurazione di un server CTF di sicurezza

Non ho esperienza in esecuzione o impostazione di una cosa del genere, ma qui ci sono i miei pensieri su come evitare rischi indebiti:

• È necessario un monitoraggio esterno sui servizi critici sulla VM. Un exploit che causa un crash lo rovinerebbe sicuramente per tutti gli altri. Sarebbe OK se qualcuno decifra il sito web in esecuzione sulla scatola fintanto che tutti i link necessari ad altre pagine rimangono intatti ma se lo sfigurano così male che il resto del sito diventa irraggiungibile o inizia a lanciare codici 500 Internal Error ai visitatori o addirittura blocca completamente il demone HTTP, che dovrebbe essere rilevato e risolto rapidamente.

• La macchina dell'attaccante potrebbe essere esposta a qualche minaccia se non la stai supervisionando. Il primo kit di exploit trovato da una ricerca su Google per il prodotto a cui mirano è altrettanto probabile che contenga malware come strumento di exploit reale.

• Rischio politico / legale. Firma i moduli di rinuncia a cui tenerli, consentendo loro in modo esplicito di tentare di sfruttare questa particolare macchina. Spiega le conseguenze dell'esecuzione di queste stesse azioni senza il modulo firmato.

E alcuni pensieri generali sull'esecuzione di questa cosa:

• Molti exploit non mostrano segni evidenti di successo. Naturalmente, questo fa parte dell'esperienza di apprendimento, per mostrare agli sviluppatori che il semplice spegnimento della visualizzazione degli errori non ostacola completamente gli aggressori competenti. Ma potrebbe essere bello avere un'interfaccia separata per mostrare il contenuto corrente della tabella utenti nel database o il contenuto di una particolare directory o l'elenco dei processi in esecuzione sulla macchina. Questo potrebbe essere qualcosa che si spegne in seguito, poiché lo sviluppatore è in grado di rilevare meglio i propri stessi successi.

• Mantieni il punteggio. Per le persone che non sono naturalmente interessate alla sicurezza, renderlo divertente è la chiave per mantenere la loro attenzione, e un po 'di competizione amichevole lo aiuterà. Se stai cercando solo una singola vulnerabilità, non sarà un punteggio tanto quanto una lista di controllo di chi lo ha fatto e chi no, ma se uno sviluppatore trova effettivamente una vulnerabilità in più rispetto a quella che ti aspettavi essere lì, dovrebbero essere pubblicamente elogiati in qualche modo.

• Dato che stai puntando questo sugli sviluppatori piuttosto che sui pen-tester, il loro lavoro diurno sarà il ruolo di difesa meno affascinante. Una volta che hanno sfruttato il codice, un'attività di follow-up potrebbe essere quella di vedere se possono proteggere il codice da soli prima di vedere la migliore soluzione che il tuo team ha trovato collettivamente.

Non ho una grande esperienza con le sfide CTF. Ma ne ho partecipato alcuni e non sono un esperto. Ma posso raccontare delle mie esperienze.

• Prima di tutto quando esegui una sfida CTF possiamo avvisare gli utenti delle cose da fare e da non fare. Ma questo non farà in modo che non lo facciano. Semplicemente possiamo dire loro di non fare il DoS ma non si assicureranno che non utilizzeranno il DoS contro il tuo server di gioco CTF
• Quando stiamo dando un servizio o un sito web da sfruttare, dovremmo assicurarci che solo questo tipo di attacco sia possibile qui e il resto della sicurezza sia stretto. Questo è successo quando io con i miei amici ho condotto una semplice competizione di hacking nel mio college. Abbiamo dato un'applicazione per hackerare. Abbiamo testato quell'applicazione per assicurarci che ci fosse una sola scappatoia. Ma i concorrenti hanno usato altri metodi complessi da sfruttare e l'hanno fatto.
• La sicurezza è tutta una questione di cattiva programmazione. Assicurati che i tuoi servizi o applicazioni non presentino scappatoie.
• Ricordo che il mio amico stava partecipando a una competizione CTF. Ha detto che ci sarà una competizione di 6 ore, ma la competizione è terminata dopo 30 minuti perché uno dei concorrenti ha sfruttato una vulnerabilità nel server CTF e tutto è crollato. Quindi le cose da fare e da non fare non sono un problema.

Semplicemente creerai solo una vulnerabilità nella tua applicazione da sfruttare. Ma gli sfruttatori faranno tutti i tipi di test per romperlo perché non sanno quale sia l'esatta vulnerabilità qui. Potrebbe essere una piccola scappatoia che ti è sfuggita comprometterebbe il tuo server.

Credo che stripe.com abbia eseguito 2 contest di CTF.

Discutono del design nel seguente post del blog. Potresti trovarlo utile:

link

Per i sistemi Linux e Unix, suggerisco di creare una sorta di stato rigurgitato ogni 24 ore tramite una piattaforma come - collegamento - che funziona tramite avvio PXE (probabilmente aiuterebbe a capire scripting e cronjobs). Fondamentalmente, imposta un gruppo di macchine (virtuali o meno) e chiedi loro di dare il via a una nuova immagine di base una volta al giorno.

Per un sistema di punteggio, controlla questo link del codebase codebase  - o forse questo - link

Se ti piacciono Ubuntu e Vagrant, controlla il server CTF di Facebook - link

Probabilmente la migliore piattaforma di base è - link - e puoi leggere questa sezione - link - che include documenti che coprono le insidie di gestire un CTF senza una preparazione e una pianificazione adeguate.

I team DEF CON CTF e HackUCF hanno anche fornito i loro codebase su GitHub - link - link

Anche uno dei miei colleghi ha aperto il suo tabellone e il server CTF qui - link