Content uploaded by Paulo Matias
Author content
All content in this area was uploaded by Paulo Matias on Oct 26, 2017
Content may be subject to copyright.
Provisionamento automatizado de servidores para
competic¸ ˜
oes de seguranc¸a da informac¸˜
ao
Lucas Magalh˜
aes1, Antˆ
onio Carlos F. Petri1, Gabriel de S. Alves1,
Cesar Augusto C. Marcondes1, Paulo Matias1
1Departamento de Computac¸˜
ao
Universidade Federal de S˜
ao Carlos (UFSCar)
S˜
ao Carlos, SP – Brasil
whoisroot@openmailbox.org, {falcaopetri, g4briel.4lves}@gmail.com,
{marcondes, matias}@dc.ufscar.br
Abstract.
Promoting Capture-The-Flag (CTF) competitions requires large ope-
rational costs, due to the number of participants scale and problems computing
requirements. In problems that involve server exploitation, it is important to
provide guarantees that each participant solution do not interfere with others.
Thus, to save resources, we propose an automated provisioner that allocates
LXD containers to competitors that have achieved a minimum score, in addition
we integrate the provisioner to the OpenStack API. Finally, the solution is fully
operational at UFSCar Private Cloud and we plan to adopt it during the 2017
Pwn2Win International CTF.
Resumo.
Promover competi
c¸ ˜
oes de Capture-The-Flag (CTF) pode envolver um
grande custo operacional, pois a complexidade da infraestrutura escala com o
n
´
umero de participantes e de problemas propostos. Em problemas que envolvam
explorar servidores,
´
e necess
´
ario garantir que as a
c¸ ˜
oes de um participante n
˜
ao
impactem na resolu
c¸ ˜
ao de outros. Para economizar recursos, desenvolvemos
um provisionador autom
´
atico que aloca cont
ˆ
eineres LXD apenas para compe-
tidores que obtenham previamente uma pontua
c¸ ˜
ao m
´
ınima em problemas que
n
˜
ao envolvam explorar servidores, al
´
em de integrar-se
`
a API do OpenStack. A
solu
c¸ ˜
ao encontra-se totalmente operacional na nuvem privada da UFSCar, e
pretendemos adot´
a-la na edic¸ ˜
ao de 2017 do CTF internacional Pwn2Win.
1. Motivac¸ ˜
ao
Um elemento cr
´
ıtico de uma estrat
´
egia efetiva de ciberseguran
c¸
a
´
e dispor de pessoas
treinadas nas quest
˜
oes mais recentes relacionadas
`
a seguran
c¸
a da informa
c¸˜
ao. Alguns
pa
´
ıses, como os Estados Unidos, t
ˆ
em se preparado de forma expressiva contra ataques
cibern
´
eticos [
ABI Research 2015
], no entanto, ainda h
´
a uma limita
c¸˜
ao na quantidade e
na qualidade dos profissionais, especialmente quando consideramos habilidades mais
sofisticadas, tais como seguran
c¸
a por constru
c¸˜
ao, intelig
ˆ
encia de amea
c¸
as, ou per
´
ıcia
forense ap´
os um ataque [Evans and Reeder 2010].
Com o objetivo de reduzir a car
ˆ
encia do mercado em profissionais de
ciberseguran
c¸
a, empresas, escolas, universidades e institui
c¸ ˜
oes militares ao redor do mundo
t
ˆ
em promovido competi
c¸ ˜
oes de “capture a bandeira” (ou CTF, do ingl
ˆ
es Capture-The-
Flag) para incentivar que mais profissionais envolvam-se com t
´
opicos de ciberseguran
c¸
a.
Competi
c¸ ˜
oes de CTF geralmente s
˜
ao planejadas para proporcionar aos participantes ex-
peri
ˆ
encia em um amplo espectro de problemas relacionados
`
a seguran
c¸
a de computadores,
bem como em t
´
ecnicas de ataque e defesa que poderiam ser aplicadas em situa
c¸ ˜
oes reais.
Essas competi
c¸ ˜
oes tamb
´
em podem servir como uma alternativa de baixo custo para recrutar
profissionais altamente habilidosos para preencher vagas espec
´
ıficas de emprego. Dentre
as habilidades necess
´
arias para participar de CTFs, citamos engenharia reversa, explora
c¸˜
ao
de falhas em bin´
arios e em aplicativos web, an´
alise forense, criptan´
alise e programac¸˜
ao.
H
´
a dois estilos de competi
c¸˜
ao de CTF: ataque/defesa ejeopardy. Em competi
c¸ ˜
oes
de ataque/defesa, cada equipe recebe uma m
´
aquina para defender, conectada a uma rede
isolada. A pontua
c¸˜
ao das equipes
´
e dada com base tanto no sucesso em defender essa
m
´
aquina como no
ˆ
exito em atacar as m
´
aquinas de outras equipes. Competi
c¸ ˜
oes de jeopardy
s
˜
ao mais comuns e geralmente envolvem m
´
ultiplas categorias de problemas, cada qual
contendo uma variedade de desafios com diferentes pontua
c¸ ˜
oes e n
´
ıveis de dificuldade.
Resolver corretamente o problema leva o competidor a obter uma bandeira (flag), que deve
ser submetida para uma plataforma a fim de computar pontos no placar. As equipes tentam
obter a maior pontua
c¸˜
ao poss
´
ıvel ao longo da competi
c¸˜
ao (e.g., num per
´
ıodo de 24 horas),
mas geralmente n
˜
ao atacam diretamente uma
`
a outra. Ao contr
´
ario de uma corrida, esse
estilo de jogo estimula as equipes a dedicar tempo para estudar os desafios, e prioriza a
quantidade de submiss˜
oes corretas em vez da velocidade com que s˜
ao submetidas.
Dentre os desafios propostos em competi
c¸ ˜
oes de jeopardy, h
´
a um subconjunto
que disponibiliza um arquivo para que os participantes copiem e resolvam o problema
localmente em seus computadores. Geralmente enquadram-se nesse grupo os desafios das
categorias de engenharia reversa, an
´
alise forense e criptan
´
alise. Muitas vezes, h
´
a tamb
´
em
um subconjunto de problemas que, apesar de requerer ataques a um servidor, n
˜
ao solicitam
que o participante tome controle por completo nem altere o estado desse servidor. Por
exemplo, para resolver alguns tipos de problema de explora
c¸˜
ao de falhas em aplicativos
web vulner
´
aveis a inje
c¸˜
ao de SQL (Structured Query Language), basta realizar consultas
somente de leitura (e.g.,
SELECT
). Nesse caso,
´
e poss
´
ıvel configurar o servidor de forma
que a base de dados mantenha-se congelada e n˜
ao possa ser alterada pelos participantes.
No entanto, a imensa maioria dos problemas de explora
c¸˜
ao de bin
´
arios e de apli-
cativos web exige que os participantes executem a
c¸ ˜
oes que alteram o estado do servidor
ao longo do processo de resolu
c¸˜
ao. Nesses casos,
´
e necess
´
ario prover uma infraestrutura
separada para cada equipe, a fim de impedir que as demais equipes causem indisponibili-
dade ou tomem qualquer a
c¸˜
ao que dificulte a resolu
c¸˜
ao do problema. Por exemplo, em
um desafio que envolva tomar controle por completo de um servidor compartilhado entre
diversas equipes, a primeira equipe a resolver o problema poderia remover as bandeiras
desse servidor, impedindo que outras equipes conclu
´
ıssem a resolu
c¸˜
ao. A interfer
ˆ
encia
entre diversas equipes tamb
´
em poderia ocorrer de forma acidental, pela simples disputa
entre acessos de escrita originados por equipes distintas de forma concorrente.
Para resolver esse problema, diversas competi
c¸ ˜
oes t
ˆ
em adotado uma infraestrutura
baseada em cont
ˆ
eineres, na qual cada equipe recebe um cont
ˆ
einer diferente para um
determinado desafio. Cont
ˆ
eineres s
˜
ao alternativas leves
`
as m
´
aquinas virtuais que, no caso
do Linux, s
˜
ao implementadas usando os recursos de espa
c¸
o de nomes e de grupos de
controle do sistema operacional. Apesar do n
´
ucleo do sistema operacional apresentar
uma
´
area de ataque maior que a de um virtualizador, essa tecnologia vem se mostrando
competitiva em diversos cen´
arios de aplicac¸˜
ao [Bernstein 2014].
2. Proposta e Principais Funcionalidades
Este trabalho prop
˜
oe uma ferramenta de software livre capaz de provisionar uma infraes-
trutura baseada em cont
ˆ
eineres para uma competi
c¸˜
ao de CTF em uma nuvem OpenStack
p´
ublica ou privada disponibilizando, ainda, as seguintes inovac¸˜
oes:
•
Nossa ferramenta gerencia cont
ˆ
eineres sem depender de solu
c¸ ˜
oes internamente
complexas, como a plataforma Kubernetes. Apesar de est
´
avel e de f
´
acil utiliza
c¸˜
ao,
a plataforma Kubernetes tem demonstrado possuir uma
´
area de ataque demasiada-
mente ampla para ser adotada em CTFs nos quais os competidores possam vir a
tomar controle por completo de alguns dos cont
ˆ
eineres. Em competi
c¸ ˜
oes nas quais
foi adotada, ocorreram problemas devido a configura
c¸ ˜
oes padr
˜
ao inseguras, tais
como permiss
˜
ao de acesso
`
a API de dentro dos cont
ˆ
eineres [
Eastes 2017
]. Apesar
de existirem esfor
c¸
os recentes em prover recursos e orienta
c¸ ˜
oes de seguran
c¸
a para
a plataforma Kubernetes, optamos por uma solu
c¸˜
ao mais simples e menos sujeita
a erros. Gerenciamos os servidores por meio de comandos enviados via SSH
(Secure Shell) e utilizamos somente cont
ˆ
eineres providos pelo LXD, projeto cujo
foco
´
e justamente ser seguro por padr
˜
ao, fornecendo uma alternativa mais leve
a virtualizadores [
Ernst et al. 2016
,
Ferreira 2017
]. Com isso, perdemos alguns
recursos da plataforma Kubernetes, como o provimento de infraestruturas com alta
disponibilidade (por meio de r
´
eplicas do n
´
o mestre). No entanto, argumentamos
que esse recurso n
˜
ao
´
e t
˜
ao importante em CTFs, podendo ser substitu
´
ıdo pelo
monitoramento da infraestrutura.
•
Provisionamos cont
ˆ
eineres apenas para as equipes que atingirem uma determinada
pontua
c¸˜
ao m
´
ınima nos problemas que n
˜
ao dependam de cont
ˆ
eineres, ou seja, aque-
les que possam ser resolvidos pelos participantes localmente em seus computadores,
ou que tenham sido elaborados de forma a garantir que todas as opera
c¸ ˜
oes efetuadas
em um servidor sejam somente de leitura. Desta forma, economizamos recursos
computacionais que seriam alocados para equipes que se inscreveram mas n
˜
ao
possuem a inten
c¸˜
ao de participar seriamente da competi
c¸˜
ao. CTFs divulgados no
s
´
ıtio CTFtime
1
, que re
´
une e avalia por pares diversas competi
c¸ ˜
oes internacionais,
costumam receber centenas de inscri
c¸ ˜
oes de equipes. Em edi
c¸ ˜
oes anteriores da
competi
c¸˜
ao Pwn2Win, observamos que apenas pouco mais da metade das equipes
inscritas chega a resolver ao menos um dos problemas propostos [Bertochi 2016].
•
Nosso provisionador integra-se
`
aNIZKCTF, uma plataforma abertamente audit
´
avel
e resistente a ataques contra seu mecanismo de placar [
Matias et al. 2017
]. O
provisionador monitora continuamente o placar da plataforma NIZKCTF para
determinar se uma equipe possui pontua
c¸˜
ao m
´
ınima para ter acesso aos cont
ˆ
eineres.
Al
´
em disso, cont
ˆ
eineres associados a problemas que j
´
a tenham sido resolvidos por
uma equipe s˜
ao automaticamente destru´
ıdos, por n˜
ao serem mais necess´
arios.
3. Importˆ
ancia da Seguranc¸a da Infraestrutura de CTFs
Uma preocupa
c¸˜
ao constante para organizadores de CTFs
´
e proteger de ataques a infra-
estrutura da competi
c¸˜
ao, que est
´
a sujeita
`
as mesmas falhas de seguran
c¸
a que qualquer
1https://ctftime.org
sistema computacional. Devido
`
a elevada competitividade entre os participantes,
´
e comum
encontrar equipes atacando a infraestrutura em vez dos desafios propostos pela competi
c¸˜
ao.
Um exemplo dessa situa
c¸˜
ao ocorreu durante o RC3 CTF de 2016. Por um momento
durante essa competi
c¸˜
ao, uma equipe denominada “The board is vulnerable, please contact
admin@seadog007.me” apareceu no placar com 4500 pontos [
Yu 2016
]. A Figura 1 mostra
o registro desse fato. Felizmente, a inten
c¸˜
ao do participante que explorou a falha era apenas
reportar a vulnerabilidade para os administradores. Entretanto, era perfeitamente poss
´
ıvel
explor´
a-la para fins maliciosos.
Figura 1. Durante o RC3 CTF de 2016, um competidor explorou falhas no
mecanismo de placar para reportar a vulnerabilidade aos administradores da
competic¸ ˜
ao.
Um dos componentes de uma competi
c¸˜
ao de CTF mais visados em ataques
´
e a
plataforma central que recebe submiss
˜
oes de respostas (bandeiras) e gerencia o placar.
Visando proteger esse mecanismo nas competi
c¸ ˜
oes em que for adotada, a ferramenta
apresentada neste artigo foi desenvolvida para integrar-se
`
aNIZKCTF, uma plataforma
para CTFs que propomos recentemente [
Matias et al. 2017
], que baseia sua seguran
c¸
a em
provas criptogr
´
aficas em vez de confiar na seguran
c¸
a do software ou dos servidores que o
hospedam. Em lugar de submeter diretamente as respostas (bandeiras) para a plataforma, o
competidor envia uma prova de conhecimento zero de que obteve a resposta correta. Essa
prova criptogr
´
afica n
˜
ao cont
´
em nenhuma informa
c¸˜
ao que possa auxiliar outras equipes
a resolver o problema, e
´
e tornada p
´
ublica para que qualquer observador externo possa
auditar a competi
c¸˜
ao. A Figura 2 ilustra a arquitetura geral da implementa
c¸˜
ao da plataforma
NIZKCTF, que utiliza somente servi
c¸
os disponibilizados gratuitamente (at
´
e limites da
ordem de 1 milh˜
ao de requisic¸ ˜
oes) pela nuvem p´
ublica da Amazon.
Al
´
em da preocupa
c¸˜
ao em adotar uma plataforma central segura, a ferramenta
proposta neste artigo foi projetada para provisionar uma infraestrutura que resista aos
modelos de advers´
ario descritos ao final da sec¸˜
ao a seguir.
Local Git
Repository
AWS
Lambda
Player
Pull Request Pull Request
Pull Request
Trigger Merge Pull
Request
Local Git
Repository
Central Git
Repository
AWS API
Gateway
AWS
SNS
Player
Figura 2. Vis ˜
ao geral da plataforma NIZKCTF ,`
a qual o provisionador integra-se.
Os competidores modificam reposit ´
orios Git locais e criam pull requests para
o reposit ´
orio central. Uma func¸ ˜
ao AWS Lambda ´
e disparada para integrar as
alterac¸ ˜
oes ao reposit ´
orio central caso as mudanc¸as sejam v ´
alidas.
4. Infraestrutura Provisionada e Modelos de Advers´
ario
A Figura 3 apresenta a infraestrutura provisionada pela solu
c¸˜
ao proposta neste artigo.
Como forma de provisionamento inicial, utilizamos a ferramenta Ansible para preparar
um certo n
´
umero de m
´
aquinas virtuais para receber cont
ˆ
eineres de desafios, al
´
em de uma
m´
aquina virtual espec´
ıfica para abrigar contˆ
eineres de VPN (Virtual Private Network).
Na rede gerenciada pelo componente Neutron do OpenStack, a ferramenta proposta
por esse artigo aloca uma vlan para cada equipe que atingir a pontua
c¸˜
ao m
´
ınima necess
´
aria
para ter acesso aos cont
ˆ
eineres. Todas as m
´
aquinas virtuais possuem acesso a todas as
vlans, por
´
em internamente a essas m
´
aquinas conectamos cada vlan apenas ao cont
ˆ
einer
alocado para a respectiva equipe.
Os cont
ˆ
eineres de VPN s
˜
ao configurados com certificados TLS (Transport Layer
Security) emitidos por uma autoridade comum, gerenciada pela pr
´
opria ferramenta. Os
times acessam essas inst
ˆ
ancias por meio de um roteamento NAT (Network Address Trans-
lation) reverso. Cada equipe recebe o n
´
umero da porta que
´
e internamente roteada para
seu contˆ
einer de VPN, juntamente com um usu´
ario e uma senha aleat´
oria para conex˜
ao.
Cont
ˆ
eineres contendo um mesmo desafio s
˜
ao provisionados sempre na mesma
m
´
aquina virtual. Como utilizamos ZFS para armazenar os dados dos cont
ˆ
eineres, essa
organiza
c¸˜
ao permite aproveitar ao m
´
aximo os recursos de c
´
opia na escrita (copy-on-write)
desse sistema de arquivos. Ao provisionar um desafio para uma nova equipe, os blocos
de armazenamento n
˜
ao s
˜
ao clonados, apenas referenciados. No decorrer da competi
c¸˜
ao,
apenas blocos que desviem do conte
´
udo original causar
˜
ao um aumento do espa
c¸
o em disco
ocupado na m´
aquina virtual.
Figura 3. Infraestrutura provisionada pela ferramenta proposta. Cada time ´
e alo-
cado em um contˆ
einer distinto, dentro de m´
aquinas virtuais diferentes para cada
problema. As equipes acessam a rede interna da competic¸ ˜
ao via VPN.
Al
´
em disso, a organiza
c¸˜
ao proposta prov
ˆ
e propriedades interessantes de seguran
c¸
a
quando adotados os seguintes modelos de advers´
ario:
•
Um advers
´
ario que possua acesso a uma falha de dia zero (zero day) que permita
escapar de cont
ˆ
eineres, e pretenda obter as respostas (bandeiras) de problemas
que n
˜
ao tenha resolvido: Neste caso, o advers
´
ario n
˜
ao conseguir
´
a escapar de um
problema para outro, assumindo que este n
˜
ao tenha acesso a uma falha de dia zero
do virtualizador.
•
Um advers
´
ario que possua acesso a uma falha de dia zero (zero day) que permita
escapar de cont
ˆ
eineres, e pretenda apagar ou corromper dados dos cont
ˆ
eineres de
outros times: Neste caso, o advers
´
ario precisa ao menos come
c¸
ar a resolver cada
um dos problemas antes de perpetuar o ataque. Caso tenha obtido acesso para
executar c
´
odigo remoto em apenas uma das m
´
aquinas virtuais, somente conseguir
´
a
explorar a falha de dia zero nessa m´
aquina.
5. Arquitetura da Ferramenta
O processo principal da ferramenta
´
e implementado por um
´
unico script escrito em
linguagem Python. Esse script monitora constantemente o arquivo de submiss˜
oes aceitas
gerado pela plataforma NIZKCTF e, por meio da fun
c¸˜
ao
compute target state
,
calcula o estado final desejado, ou seja, quais cont
ˆ
eineres devem estar alocados em cada
m´
aquina virtual, dada a lista de desafios resolvidos por cada time.
Uma vez calculado o estado final, o script executa as seguintes fun
c¸ ˜
oes, em ordem:
•start vms
: assegura que as m
´
aquinas virtuais que abriguem cont
ˆ
eineres que
precisem estar dispon´
ıveis estejam ligadas;
•handle container transition
: assegura que os cont
ˆ
eineres que precisem
estar dispon
´
ıveis existam dentro das m
´
aquinas virtuais, e destr
´
oi cont
ˆ
eineres que
n˜
ao precisem estar dispon´
ıveis;
•stop idle vms
: desliga m
´
aquina virtuais que n
˜
ao estejam abrigando nenhum
contˆ
einer.
Cada transi
c¸˜
ao (cria
c¸˜
ao ou destrui
c¸˜
ao) de cont
ˆ
einer
´
e efetuada por um script em
linguagem shell previamente instalado pela ferramenta Ansible em cada m
´
aquina virtual.
A ferramenta chama esses scripts por meio de comandos SSH enviados com o aux
´
ılio da
biblioteca Paramiko.
Oscript que provisiona o cont
ˆ
einer de VPN
´
e especial pois configura as credenciais
de acesso da equipe
`
a rede interna da competi
c¸˜
ao e, portanto, precisa comunic
´
a-las de
volta
`
a equipe. Para isso, o provisionador adiciona a um reposit
´
orio Git uma mensagem
encriptada com a chave p
´
ublica da equipe, permitindo que apenas a equipe a que se destina
tenha acesso ao conte´
udo, sem exigir que o provisionador tenha acesso a contatos diretos
ou informa
c¸ ˜
oes da equipe que n
˜
ao sejam do conhecimento de todos que acompanham a
competic¸˜
ao.
Todas as opera
c¸ ˜
oes do provisionador s
˜
ao executadas em thread pools, com o
objetivo de alcan
c¸
ar melhor desempenho (reduzindo as esperas de entrada/sa
´
ıda) e de
permitir impor tempos m´
aximos de execuc¸˜
ao (timeouts).
6. Homologac¸ ˜
ao
A ferramenta proposta neste artigo foi previamente homologada, em pequena escala, em
uma competi
c¸˜
ao promovida durante a Semana de Computa
c¸˜
ao (SeComp) do Departamento
de Computac¸˜
ao da UFSCar.
Durante essa competic¸˜
ao, 4 equipes alcanc¸aram pontuac¸ ˜
ao suficiente para recebe-
rem acesso aos cont
ˆ
eineres. Foram observados apenas problemas pontuais na solu
c¸˜
ao de
provisionamento aqui proposta, tais como a inadequa
c¸˜
ao da configura
c¸˜
ao de keepalive do
OpenVPN para a rede de alguns dos participantes que estavam atr
´
as de roteadores NAT.
Todos os problemas observados puderam ser corrigidos ainda no decorrer da competic¸˜
ao.
7. Disponibilidade
O provisionador e projetos correlacionados est
˜
ao dispon
´
ıveis como software livre sob
a licen
c¸
a MIT. Todos os c
´
odigos e documenta
c¸˜
ao est
˜
ao dispon
´
ıveis nos reposit
´
orios da
competic¸˜
ao Pwn2Win no GitHub: https://github.com/pwn2winctf.
•
Documenta
c¸˜
ao de instala
c¸˜
ao da plataforma NIZKCTF (pr
´
e-requisito para reali-
zar um CTF com o provisionador):
https://github.com/pwn2winctf/
nizkctf-tutorial/blob/master/GitHub.md
•
Documenta
c¸˜
ao de instala
c¸˜
ao do provisionador:
https://github.com/
pwn2winctf/NIZKCTF-provisioning/blob/master/README.md
8. Requisitos de Hardware
O provisionador foi testado em uma m´
aquina virtual com as seguintes caracter´
ısticas:
•1 n´
ucleo de CPU de 2 GHz
•2 GB de mem´
oria RAM
•5 GB de disco
9. Demonstrac¸ ˜
ao Planejada para o SBSEG
Para o Simp
´
osio Brasileiro de Seguran
c¸
a da Informa
c¸˜
ao e de Sistemas Computacionais
(SBSeg), pretendemos instalar o provisionador proposto neste artigo em um computador
pessoal (PC) ou laptop com acesso `
a Internet a ser exposto no SBSEG.
Configuraremos o provisionador para monitorar o reposit
´
orio GitHub controlado
por uma inst
ˆ
ancia da plataforma NIZKCTF previamente configurada na Amazon. Pos-
teriormente, disponibilizaremos alguns desafios para que os participantes do Simp
´
osio
possam simular sua participa
c¸˜
ao em uma competi
c¸˜
ao. Configuraremos o provisionador
para instanciar esses desafios em m
´
aquinas virtuais na nuvem da UFSCar. Em outras
palavras, o computador fisicamente exposto na SBSEG apenas controlar
´
a m
´
aquinas virtuais
hospedadas em uma infraestrutura externa.
Alguns dos desafios ter
˜
ao a resposta (bandeira) inclu
´
ıda em seu pr
´
oprio enunciado,
a fim de permitir que mesmo aqueles que n
˜
ao tenham
`
a disposi
c¸˜
ao tempo para estudar e
resolver um problema de CTF possam avaliar o funcionamento do provisionador. Desta
forma, ao resolver ao menos um desafio que n
˜
ao tenha um servidor atrelado a si, o
expectador da demonstra
c¸˜
ao receber
´
a credenciais para acessar a VPN hospedada na nuvem
da UFSCar. Em seguida, ao resolver problemas atrelados a servidores, observar
´
a que os
contˆ
eineres correspondentes s˜
ao destru´
ıdos, e passa a n˜
ao ser mais poss´
ıvel acess´
a-los.
Referˆ
encias
ABI Research (2015). Global cybersecurity index & cyberwellness profiles. Technical
report, International Telecommunications Union, Geneva, CH.
Bernstein, D. (2014). Containers and cloud: From LXC to Docker to Kubernetes. IEEE
Cloud Computing, 1(3):81–84.
Bertochi, A. (2016). Pwn2Win CTF 2016 – Bastidores. https://ctf-br.org/2016/04/pwn2win-
ctf-2016-bastidores.
Eastes, B. (2017). Capturing all the flags in BSidesSF CTF by pwning our infrastruc-
ture. https://hackernoon.com/capturing-all-the-flags-in-bsidessf-ctf-by-pwning-our-
infrastructure-3570b99b4dd0.
Ernst, D., Bermbach, D., and Tai, S. (2016). Understanding the container ecosystem:
A taxonomy of building blocks for container lifecycle and cluster management. In
IEEE Second International Workshop on Container Technologies and Container Clouds,
Berlin, Germany. IEEE.
Evans, K. and Reeder, F. (2010). A human capital crisis in cybersecurity: Technical
proficiency matters. Technical report, Center for Strategic and International Studies,
Washington, DC, USA.
Ferreira, U. J. S. (2017). An
´
alise de tecnologias de virtualiza
c¸˜
ao e hard-
ware de baixo custo para infraestutura de nuvem de pequeno porte.
https://memoria.ifrn.edu.br/handle/1044/940.
Matias, P., Barbosa, P., Cardoso, T., Mariano, D., and Aranha, D. (2017). NIZKCTF: A non-
interactive zero-knowledge capture the flag platform. https://arxiv.org/abs/1708.05844.
Yu, J. (2016). Seadog GitHub repository: RC3-CTF-2016-scoreboard.
https://github.com/seadog007/RC3-CTF-2016-scoreboard.
