Prerequisiti: MAC: brew install libyaml sudo easy_install redis pyyaml pysphere mock WINDOWS: ez_setup c:\python27\scripts\easy_install redis pyyaml pysphere mock - REPORTLEVEL: - CHECK_STATIC: TECH - BUILD: EXECUTIVE - ON_ERROR: continue - REPORT: "windows silent" - BUILD: [ elite, windows, silent ] - REPORT: "static windows" - CHECK_STATIC: [ AVAgent/assets/* ] - BUILD: [ pull, windows, silent ] - REPORT: "static desktop" - BUILD: [ pull, linux, silent ] - BUILD: [ pull, osx, silent ] - REPORT: "static mobile" - BUILD: [ pull, android, silent ] - BUILD: [ pull, blackberry, silent ] - BUILD: [ pull, ios, silent ] - ON_ERROR: break - REPORT: "windows melt" - PUSH: [ melted.app ] - BUILD: [ elite, windows, melt ] - aprire il canale redis - manda STARTAGENT - unzip dei file accessori (tra cui la conf?) - ricevere i comandi - eseguire i comandi - update os/av - push - silent / melt - save file (con un payload) - restuire i risultati dei comandi ---------------------------- AVMaster - istanziare il demone db - gestire redis - comandare le vm - accendere, spegnere, monitare vm - riceve START da publish.py, che e' installato nativo sulle VM - push di avagent e dei file accessori (zipped) - eseguire remotamente avagent - ricezione STARTAGENT - inoltrare i comandi ad avagent - TRAMITE REDIS - raccogliere i risultati di avagent - quando riceve + END oppure va in timeout, considera chiuso il lavoro sulla vm - mandare mail di report AVAgent - aprire il canale redis - manda STARTAGENT - unzip dei file accessori (tra cui la conf?) - ricevere i comandi - eseguire i comandi - update os/av - push - silent / melt - save file (con un payload) - restuire i risultati dei comandi All'accensione della VM: - master <-> agent -> COMMAND [name] [arguments] <- ack(+SUCCESS/+FAILED) / nack (+ERROR) |> +ENDCOMMAND Commands: results: +SUCCESS: success, +ERROR: system, components, +FAILED: AV detecion STARTAGENT | +SUCCESS STARTAGENT SET_SERVER (backend,frontend) SET_PLATFORM (platform) SET_BLACKLIST (avs) PUSH (namefile, content) | +SUCCESS PUSH BUILD (kind, args) BUILD_SILENT BUILD_MELT(filehost) STATICDETECTION (dir) | +SUCCES / +FAILED EXECUTE_SIMPLE EXECUTE_SCOUT // aspetta n minuti, muove mouse, aspetta sync UPGRADE_ELITE // set upgrade, aspetta upgrade, check bl UNINSTALL Per ogni comando esiste una classe nella format command_COMMANDNAME Es: command_STARTAGENT Segue una descrizione di un piano di realizzazione di una rete di macchine virtuali atte alla verifica di visibilità delle build RCS su un insieme significativo di Antivirus e Antimalware. Obiettivo: - una VM per antivirus - ogni VM deve poter aggiornare, in momenti specificati della giornata, probabilmente di notte, OS e AV, possibilmente automaticamente - al di fuori del periodo dell'aggiornamento le VM non potranno mai connettersi ad internet. - le VM siano raggiungibili via RDP dagli sviluppatori, dalla rete 172.20.20.0/24 - le VM possano raggiungere il server (MINOTAURO) posto sulla rete 192.168.100.100/24 - le procedure di aggiornamento e di test possano essere realizzate in sicurezza in automatico Proposta: - Ci sia una macchina chiamata AVMaster che svolga le funzioni di: * gateway per le macchine AV, via NAT * AVUpdate per forzare l'update dell'OS e del AV delle VM * AVTestDispatcher per eseguire automaticamente i test sulle macchine AV. - Ogni VM abbia due interfacce: * DEV: per connettersi al server RCS e che ci consenta di connetterci via rtp. Indirizzi nella classe 192.168.100, a partire da 110. Non è specificato il Default Gateway, pertanto da questa interfaccia le VM non potranno in alcun modo raggiungere internet. * AV: per connettersi al AVMaster che ne è Default Gateway, così da poter raggiungere Internet. - Siccome le VM per raggiungere Internet sfruttano il NAT offerto da AVMaster, sull'interfaccia AV, questo può, con sicurezza, disabilitare la raggiungibilita' di tutte le VM in un comando solo. Realizzazione: Siccome occorre avere le VM pronte nel più breve tempo possibile, abbiamo speso un paio d'ore per realizzare la struttura di AVMaster e del templare delle VM sul VSphere, così da consentire la testabilita' manuale degli AV in una prima fase, ma permettere anche lo sviluppo in tempi brevi degli step successivi. La macchina AVMaster (DEV 172.20.20.167, AV 10.0.20.2 ) è una Linux Ubuntu, dispone di due cartelle di script ShoreWall, una di nome "natenabled", l'altra "natdisabled". La macchina Template (DEV 192.168.100.110, AV 10.0.20.61) è Windows 7 enterprise N. - Creata cartella c:/SHARE per la condivisione dei file - Aggiunte le rotte statiche per raggiungere i DNS e route -p ADD 172.20.20.0 MASK 255.255.255.0 192.168.100.1 route -p ADD 192.168.200.0 MASK 255.255.255.0 192.168.100.1 elevate -c route -p DELETE 192.168.200.0 MASK 255.255.255.0 192.168.100.1 elevate netsh interface ip set dns name="Local Area Connection 2" static None Matteo sta cominciando a migrare le VM esistenti secondo questo paradigma e a realizzare quelle mancanti, per arrivare ad avere, se ce la facciamo, entro domani o dopo, tutte e 20 le VM richieste. SERVE AIUTO PER L'INSTALLAZIONE, CERCHIAMO VOLONTARI. Gli script: (da fare) AVUpdate.py (eseguito su AVMaster) switch network ON for $vm in VMList: revert $vm lastgoodsnaphot start $vm execute $vm updateOS (sleep 2h) reboot $vm snapshot $vm lastgoodsnaphot stop $vm switch network OFF AVTestDispatcher.py switch network OFF for $vm in VMList: start $vm upload $vm testAV execute $vm testAV TestAV.py if ping gmail? return delete target $target create target $target create factory $factory copy config $factory build silent/melted execute silent/melted sleep / auto mouse verify $target contains instances Dipendenze: - Flask (with Flask-SQLAlchemy) - Redis - SQLite / MySQL / PostgreSQL Database (via Flask-SQLAlchemy) and Python APIs