reiner henrique dos santos filho - reiner.pdf · iii reiner henrique dos santos filho provendo...
TRANSCRIPT
Universidade Federal Fluminense
Centro Tecnologico
Escola de Engenharia
Graduacao em Engenharia de Telecomunicacoes
Reiner Henrique dos Santos Filho
Provendo seguranca da informacao em um projeto de
cidades inteligentes
Niteroi – RJ
2019
i
Reiner Henrique dos Santos Filho
Provendo seguranca da informacao em um projeto de cidades inteligentes
Trabalho de Conclusao de Curso apresentado ao
Curso de Graduacao em Engenharia de Teleco-
municacoes da Universidade Federal Fluminense,
como requisito parcial para obtencao do Grau de
Engenheiro de Telecomunicacoes.
Orientador: Profa. Natalia Castro Fernandes
Niteroi – RJ
2019
ii
.
.
iii
Reiner Henrique dos Santos Filho
Provendo seguranca da informacao em um projeto de cidades inteligentes
Trabalho de Conclusao de Curso apresentado ao
Curso de Graduacao em Engenharia de Teleco-
municacoes da Universidade Federal Fluminense,
como requisito parcial para obtencao do Grau de
Engenheiro de Telecomunicacoes.
Aprovada em 27 de maio de 2019.
BANCA EXAMINADORA
Profa. Dra. Natalia Castro Fernandes - Orientadora
Universidade Federal Fluminese - UFF
Profa. Dra. Dianne Scherly Varela de Medeiros
Universidade Federal Fluminese - UFF
Profa. Dra. Fernanda Goncalves de Oliveira Passos
Universidade Federal Fluminese - UFF
Niteroi – RJ
2019
iv
Resumo
A Universidade Federal Fluminense esta desenvolvendo uma solucao de cerca inteligente
para monitorar de forma eficiente todos os veıculos que entram e saem da cidade de Volta
Redonda, no estado do Rio de Janeiro. Esta solucao consiste em um sistema que utiliza
informacoes coletadas por cameras nas entradas, nas saıdas e no interior da cidade para
dar suporte a realizacao de acoes de seguranca publica. A proposta deste trabalho e pro-
jetar e implementar uma solucao de seguranca de sistemas computacionais que reduza as
possibilidades de ataques ao sistema via rede de comunicacao. A proposta utiliza uma
gama de ferramentas diferentes, entre elas controle de acesso via sistema de autenticacao
e configuracoes de firewall, escritas seguindo a arquitetura e organizacao proposta pela
plataforma Web Django. Para administracao de facil utilizacao e acesso, foi criado um sis-
tema Web em cima do arcabouco Django, muito usado para desenvolvimento de sistemas
desse tipo.
Palavras-chave: Django. Python. Arquitetura MVC. Iptables. Shell-script. Apa-
che. Seguranca da informacao. Cidades Inteligentes. Cerca Inteligente. firewall. iptables.
v
Abstract
The Universidade Federal Fluminense is developing a Smart Perimeter solution to effici-
ently monitor all of the vehicles that get in and out the Volta Redonda city in Rio de
Janeiro. This solution uses information collected by cameras placed in the city’s entrances,
exits, and inner city to trigger actions to improve public security. This work proposal is to
develop a computational system security solution that reduces the odds of attacks to the
system that may come by the network, and achieve this using different tools, like access
control using authentication and firewall configuration written in agree of organization
and architecture established by Django Web Platform.
Keywords: Django. Python. MVC Architecture. Iptables. Shell-script. Apache.
Network Security Smart Cities. Smart Perimeter. firewall. iptables.
vi
“Eu vou escalar ate o topo! Porque nossos
sonhos sao feitos em cima daquilo que reali-
zamos” - Black Clover.
vii
Agradecimentos
A minha avo e pais, Maria de Lourdes, Marcia e Reiner, que me deram o apoio moral e
financeiro para que pudesse superar os desafios.
A minha namorada, Lyvia Lahnnder, que durante a maior parte de minha vida academica
me ajudou de todas as formas que podia.
Ao meu professor de Geometria Analıtica, Fabio Henrique, que e o grande responsavel
por eu ter feito este curso.
A minha Orientadora, Natalia Castro, por ter me apresentado ferramentas que viriam a
me fazer me destacar em meu trabalho. E por ultimo mas nao menos importante, ao
professor Luıs Kowada, meu grande mentor.
Lista de Figuras
2.1 Diagrama dos componentes do sistema de monitoramento . . . . . . . . . . 11
3.1 Arquitetura proposta . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
3.2 Exemplo de como pode funcionar uma relacao de frontend e backend . . . 16
3.3 Django Reinhardt, guitarrista de jazz do seculo XX . . . . . . . . . . . . . 17
3.4 Diagrama da arquitetura MVC. . . . . . . . . . . . . . . . . . . . . . . . . 17
3.5 Exemplo da Interface Django admin customizada. . . . . . . . . . . . . . . 18
3.6 Pagina de login. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
3.7 Exemplo de 3 diferentes temas da aplicacao de e-mails Zimbra . . . . . . . 20
3.8 Estrutura do pacote RADIUS. Imagem retirada da RFC2866. . . . . . . . 22
3.9 Esquema de multiplas tentativas falhas de login. . . . . . . . . . . . . . . . 24
3.10 Arquitetura do iptables. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
3.11 Comparacao de um conteiner Docker e uma maquina virtual. . . . . . . . . 34
3.12 Configuracao do apache. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
3.13 Esquematizacao de um ataque MITM (Man In The Middle). . . . . . . . . 37
4.1 Demonstracao da primeira pagina criada no modulo de tracing. . . . . . . . 39
4.2 Demonstracao da segunda pagina criada no modulo de tracing. . . . . . . . 40
5.1 Mensagem ao errar as credenciais de autenticacao ate quatro vezes. . . . . 42
5.2 Mensagem apos quatro falhas. . . . . . . . . . . . . . . . . . . . . . . . . . 42
5.3 Entrada na tabela de log na black list. . . . . . . . . . . . . . . . . . . . . 42
5.4 Erro de adicao de usuario. . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
5.5 Erro de adicao de agent. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
5.6 Erro de adicao de rede no sistema. . . . . . . . . . . . . . . . . . . . . . . 44
viii
ix
5.7 Adicao de rede no sistema com exito. . . . . . . . . . . . . . . . . . . . . . 45
5.8 Alerta de falta de conexao. . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
5.9 Formulario proposto para configuracao simples do firewall. . . . . . . . . . 46
5.10 Tabela iptables mostrada no formulario. . . . . . . . . . . . . . . . . . . . 46
5.11 Alerta de falha na conexao. . . . . . . . . . . . . . . . . . . . . . . . . . . 46
Conteudo
Resumo iv
Abstract v
Agradecimentos vii
Lista de Figuras ix
Lista de Tabelas ix
1 Introducao 1
1.1 Motivacao . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.2 Objetivo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.3 Organizacao do Texto . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
2 Principais conceitos relacionados a seguranca em cidades inteligentes 4
2.1 Seguranca publica e as cidades inteligentes . . . . . . . . . . . . . . . . . . 5
2.2 Centros integrados de comando e controle . . . . . . . . . . . . . . . . . . 6
2.3 Reconhecimento optico de caracteres (OCR) . . . . . . . . . . . . . . . . . 6
2.4 Cercas inteligentes (Smart Perimeters) . . . . . . . . . . . . . . . . . . . . 7
2.5 Seguranca da Informacao . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
2.5.1 Vulnerabilidade e Ameaca . . . . . . . . . . . . . . . . . . . . . . . 9
2.6 Projeto Cerca Inteligente de Volta Redonda . . . . . . . . . . . . . . . . . 9
2.6.1 Arquitetura da solucao de rastreamento de veıculos . . . . . . . . . 10
x
xi
3 Provendo seguranca da informacao para o projeto Cerca Inteligente 13
3.1 Levantamento de requisitos para a solucao proposta . . . . . . . . . . . . . 13
3.2 Escolha do arcabouco de desenvolvimento . . . . . . . . . . . . . . . . . . 15
3.2.1 Interface grafica de usuario . . . . . . . . . . . . . . . . . . . . . . 15
3.2.2 Django . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
3.3 Autenticacao . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
3.3.1 Servidor de autenticacao Freeradius . . . . . . . . . . . . . . . . . . 21
3.3.2 Prevencao contra ataques de forca bruta . . . . . . . . . . . . . . . 22
3.4 Permissoes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
3.4.1 Erro de implementacao cometido ao utilizar as ferramentas prontas
de permissoes do Django . . . . . . . . . . . . . . . . . . . . . . . . 25
3.5 Sistema de auditoria (log) . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
3.6 Configuracao do firewall . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
3.6.1 O problema de injecao . . . . . . . . . . . . . . . . . . . . . . . . . 29
3.6.2 Inclusao de Redes . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
3.6.3 Abordagem do Monitor . . . . . . . . . . . . . . . . . . . . . . . . 31
3.6.4 Abordagem dos Agentes . . . . . . . . . . . . . . . . . . . . . . . . 32
3.7 Portabilidade da instalacao usando conteineres . . . . . . . . . . . . . . . . 33
3.7.1 Docker vs. LXD . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
3.8 Servidor Web . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
3.8.1 Criptografia do Trafego . . . . . . . . . . . . . . . . . . . . . . . . . 36
4 Outras contribuicoes 38
4.1 O modulo de tracing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
5 Resultados e discussoes 41
5.1 Demonstracao de bloqueio ao ataque de forca bruta . . . . . . . . . . . . . 41
5.2 Validador de campos usuario . . . . . . . . . . . . . . . . . . . . . . . . . . 43
5.3 Demonstracao da edicao de firewall via GUI . . . . . . . . . . . . . . . . . 43
5.4 Resposta a falha em conexoes persistentes . . . . . . . . . . . . . . . . . . 45
6 Conclusao e sugestoes para trabalhos futuros 47
xii
A Formulario customizado de autenticacao 53
B Conversor de linhas iptables de string para formato de dicionario 56
C Detector de mudancas nas linhas do firewall 57
Capıtulo 1
Introducao
Vive-se hoje na era da informacao, e, cada vez mais, evolui o ato de coletar dados de forma
a transpor o mundo real para o mundo virtual. Aplicando esse conceito no contexto das
cidades inteligentes, pode-se aprimorar o trabalho de gestao governamental. Nesse sentido,
tem-se o objetivo de cruzar informacoes para o aprimoramento de polıticas publicas e a
capacidade de gestao de recursos de maneira eficiente para melhorar a qualidade de vida
dos habitantes.
Varias sao as iniciativas de acoes dentro desse tema. Uma delas e o projeto do
COR (Centro de Operacoes do Rio), que juntamente aos outros projetos, Porto maravilha
e Central 1746, permitiu a cidade do Rio de Janeiro ganhar o premio de cidade inteligente
do ano em 2013, em Barcelona, no Smart City World Award [1]. Outros bons exemplos de
projetos que se enquadram nestes padroes sao os projetos de Smart Perimeters ou cercas
inteligentes, que buscam um controle ou, minimamente, um monitoramento do acesso a
determinado local, para geracao de relatorios, movimentacao tatica das forcas armadas
para dada area, etc. E possıvel construir uma cerca inteligente que realiza um monito-
ramento pela leitura de placas de veıculos utilizando um sistema do tipo OCR (Optical
Character Recognition) que faz o reconhecimento dos caracteres para o armazenamento e
tratamento dos dados.
2
1.1 Motivacao
No contexto de cidades inteligentes, muitas informacoes sensıveis do cidadao, como suas
rotinas diarias, sao capturadas por cameras e sensores. Esses dados podem ser de grande
valor para pessoas mal intencionadas, de forma que limitar o acesso a esses dados e
necessario. A seguranca da informacao e uma grande preocupacao nos dias de hoje, nao
so para empresas privadas como tambem para municıpios. Questoes chaves como quem
tera acesso a informacao, quem podera trata-la e quem podera fazer modificacoes, sao de
grande importancia nesse contexto. Para evitar que a resposta dessa trinca de perguntas
seja “qualquer um” devido a interceptacoes dos dados ou invasoes nos sistemas, boas
praticas de seguranca se tornam inestimaveis recursos de prevencao.
O projeto de cerca inteligente em desenvolvimento pela Universidade Federal
Fluminense (UFF) utiliza um sistema OCR para leitura e reconhecimento de placas vei-
culares, com o intuito de promover uma gestao da circulacao de veıculos na cidade de
Volta Redonda no estado do Rio de Janeiro. Tal operacao, assim como outras de segu-
ranca e gestao municipal, e tratada no Centro Integrado de operacoes e Seguranca publica
(CIOSP). O CIOSP e um orgao publico que tem como objetivo prover os recursos neces-
sarios para uma melhor eficiencia e qualificacao dos orgaos de seguranca publica. Assim,
o projeto da UFF visa tornar o CIOSP mais inteligente, permitindo uma maior seguranca
para os cidadaos de Volta Redonda.
1.2 Objetivo
Confidencialidade, disponibilidade e integridade sao conceitos primarios da seguranca da
informacao [2]. O objetivo principal deste trabalho e planejar e implementar medidas
de seguranca da informacao seguindo esses tres conceitos no projeto de Cerca Inteligente
para o CIOSP de Volta Redonda, de modo a tambem facilitar a troca das configuracoes
do sistema para os usuarios. Um objetivo secundario desse trabalho de conclusao de curso
e contribuir em aprimoramentos de outros modulos do sistema de cerca inteligente, como
buscar formas de reduzir os custos do projeto, uma melhor organizacao do banco de dados,
3
uma interface de usuario amigavel, etc.
1.3 Organizacao do Texto
Este trabalho esta dividido em seis capıtulos. Neste, e apresentada uma introducao do
tema, em comunhao com o objetivo e a motivacao para o trabalho.
No Capıtulo 2, sao abordados alguns conceitos importantes para o entendimento
do que foi realizado. Entre estes conceitos, cidades inteligentes, cercas inteligentes e
seguranca da informacao. Alem de mostrar como estava a situacao do projeto antes da
implementacao do sistema proposto neste trabalho.
No Capıtulo 3, e apresentada a arquitetura de seguranca da informacao proposta
neste trabalho para o projeto de cerca inteligente. Cada uma das ferramentas utilizadas
e explicada, destacando o porque de cada uma ter sido sugerida e como e feita a imple-
mentacao. Por fim, e apresentado um resumo da arquitetura do sistema com as mudancas
propostas.
No Capıtulo 4, outras pequenas contribuicoes dentro do mesmo projeto que
nao dao destaque a seguranca do sistema sao citadas, mais especificamente em relacao a
interface que o usuario utiliza para interagir com o sistema.
No Capıtulo 5, os resultados das implementacoes sao demonstrados em forma de
imagens com uma breve remissao sobre a qual parte do projeto eles pertencem.
Finalmente, no Capıtulo 6, as conclusoes sao apresentadas em conjunto com
sugestoes para trabalhos futuros.
Capıtulo 2
Principais conceitos relacionados a
seguranca em cidades inteligentes
Smart City ou cidade inteligente e um conceito originado a partir da convergencia entre as
palavras “tecnologia” e “cidade”, como uma solucao para remediar os constantes desafios
criados pela urbanizacao e como um facilitador para a geracao de um futuro urbano mais
sustentavel [3]. Uma cidade inteligente visa adotar medidas para contribuir positivamente
na economia local, promover uma melhor interacao com o governo e aprimorar a qualidade
de vida dos cidadaos utilizando tecnologias da informacao e comunicacao [4].
Varios sao os exemplos de implantacao de cidades inteligentes pelo mundo. A
cidade de Songdo na Coreia do Sul e uma das referencias quando se pensa em Smart
Cities. Os predios sao conectados a sistemas de monitoramento de consumo de energia e
alarmes de incendio, de forma a otimizar o uso e reduzir o custo de manutencao. Existe
um mecanismo chamado de “pneumatico” em todos os apartamentos, atraves do qual
resıduos sao enviados diretamente para central de coleta de lixo da cidade. Alem disso,
os resıduos sao utilizados para alimentar incineradores que contribuem para geracao de
energia da cidade [5].
No campo da sustentabilidade um bom exemplo e a cidade de Copenhague, na
5
Dinamarca, que implementou cerca de 400 km de ciclovias. No centro da cidade, ha
mais bicicletas que habitantes. Aproximadamente 63% do parlamento vai trabalhar de
bicicletas todos os dias, diminuindo a emissao de CO2 na cidade [5].
2.1 Seguranca publica e as cidades inteligentes
A violencia urbana e os desastres naturais sao problemas que qualquer cidade nos dias
de hoje enfrenta. Formas de combater incidentes desses tipos podem ser tomadas de
maneira mais eficiente ao se utilizar os conceitos de cidades inteligentes [6]. Por exemplo, a
iluminacao publica pode ser acionada automaticamente nos momentos onde mais ocorrem
furtos ou apenas quando ha movimentacao na area, de forma a poupar energia ao mesmo
tempo em que dificulta a pratica de certos tipos de crime.
As melhores propostas para o aprimoramento da seguranca publica nas cidades
inteligentes surgem de um estudo inicial baseado na coleta e no tratamento de dados para
garantir eficiencia nas decisoes. Nesse contexto, o monitoramento e o armazenamento de
informacoes, seja para prevencao ou para tomadas de decisao mais rapidas, facilitam o
acesso e a execucao de medidas de combate a criminalidade, tomando acoes preventivas
contra incidentes mais comuns, alem da facil identificacao de alguma atividade irregular.
A cidade de Nairobi, no Quenia, possui uma plataforma inteligente de analise de
vıdeos estabelecida para gerenciar dados, realizar consultas, coletar evidencias, e outros
servicos, contando com cerca de 1.500 cameras de alta definicao somente no centro da
cidade. O objetivo e alcancar uma melhor coordenacao e colaboracao das polıcias, melho-
rando o tempo e qualidade das decisoes [6]. Em suma, e um exemplo de implementacao
de uma cerca inteligente.
6
2.2 Centros integrados de comando e controle
Segundo o planejamento estrategico de seguranca publica e de defesa para a Copa do
mundo FIFA Brasil 2014, disponibilizado em fevereiro de 2013, os CICCs (Centros Inte-
grados de Comando e Controle) sao locais cujo objetivo e proporcionar, em tempo real,
uma imagem fiel do panorama global e local dos eventos e dos recursos envolvidos nas
operacoes e incidentes relacionados a seguranca publica, defesa civil, seguranca privada e
mobilidade urbana, a fim de embasar a tomada de decisao por parte das instituicoes [7].
Com o intuito de garantir a seguranca do paıs em grandes eventos, a SESGE (Secretaria de
Seguranca para Grandes Eventos) implementou o SICC (Sistema Intregrado de Seguranca
Publica), com os CICCs sendo as engrenagens fundamentais para o seu funcionamento
[8].
Os CICCs herdam a metodologia proposta pela teoria do Comando e Controle
(C2) originada pelos militares e nascida nos campos de batalha. Essa teoria foi conce-
bida para tornar o processo de decisao o mais celere possıvel, com seguranca, precisao,
velocidade e tecnologia. Os CICCs sao, por definicao, operados por equipes com alto
desempenho, e com suporte de ferramentas de inteligencia e sistemas tecnologicos de ul-
tima geracao. Podem, portanto, ser considerados poderosos utensılios para a realizacao
da integracao institucional das forcas que tem o objetivo de prover seguranca, atraves da
coordenacao de esforcos em busca de um fim comum. Dessa forma, os CICCs tornam
mais eficientes as respostas do governo aos incidentes [8].
2.3 Reconhecimento optico de caracteres (OCR)
Havendo um sistema de monitoramento por cameras, e importante que existam formas de
aumentar a quantidade de informacao que se consegue retirar das imagens. Por exemplo,
se um carro passar por uma das cameras, e desejavel que o registro deste evento seja
armazenado. Existem varios veıculos da mesma marca, modelo e cor, e para diferencia-
los e interessante utilizar a combinacao de caracteres presentes na placa, que e unica para
cada veıculo. Para reconhecer os caracteres, existe uma tecnologia popular chamada de
7
Reconhecimento Otico de Caracteres (OCR, Optical, Character Recognition) [9], muito
usada para converter textos de livros para formato digital. A partir dos caracteres em
uma imagem ou mapa de bits, cabe ao OCR transforma-los em em texto capaz de ser
manipulado pelo computador.
Utilizando um sistema OCR e cameras, e possıvel registrar quando um veıculo
passa por determinado local, tornando possıvel rastrea-lo pela cidade caso seja roubado,
por exemplo, e prover alertas para que as forcas de seguranca publica tomem as devidas
providencias. A quantidade de caracteres que sao reconhecidas corretamente depende da
qualidade da imagem analisada, quanto melhor a qualidade, mais caracteres reconhecidos
corretamente.
2.4 Cercas inteligentes (Smart Perimeters)
Em toda a historia, cercas de madeira, concreto e outros materiais foram construıdas para
controle de trafego, tanto de entrada, quanto de saıda de um determinado local. Uma
escola por exemplo, possui cercas para garantir que alunos nao saiam e para evitar que
pessoas nao desejadas consigam entrar.
Partindo da premissa que o ser humano comete erros, as cercas tradicionais
possuem limitacoes. Uma pessoa pode nao ver quando alguem pular a cerca ou ingressar
sem que seja notado. Por isso, a tecnologia e bem vinda para o aprimoramento da eficiencia
das cercas. O uso da tecnologia permite que o perımetro completo passe a ter controle
de acesso eletronico e monitoramento das entradas e saıdas. Cameras termais, radares e
sensores de movimento sao alguns exemplos de dispositivos que podem ser usados para
aprimorar o monitoramento no perımetro de uma area, criando uma cerca inteligente.
Em Shanghai, na China, existem cameras moveis por toda extensao do rio Lijiang
disponıveis para o uso dos centros de comando. Estima-se que para cada incidente o tempo
medio de uma tomada de decisao da polıcia seja de 3 minutos. Apos a implementacao
dessa infraestrutura, a quantidade de ocorrencias de alguns crimes decaıram cerca de 30%
em relacao a quando nao existia a cerca inteligente. [6].
8
2.5 Seguranca da Informacao
O estudo de como proteger a disponibilidade de um servico e as precaucoes para manter
sob sigilo dados sensıveis se unem na expressao seguranca da informacao. Bem como o
nome sugere, a seguranca da informacao e traduzida como um conjunto de acoes para
garantir a protecao de dados e servicos de uma organizacao ou indivıduo. E uma area de
estudo muito ampla e que cresce constantemente devido a quantidade de novos ataques
que surgem a todo momento e tambem a estudos que preveem eventuais problemas de
seguranca. Existem seis pilares que sustentam a seguranca da informacao, sendo eles:
• Autenticidade e nao repudio: Garantia de que quem se identifica e realmente
quem diz ser e que nao possa negar ter recebido ou enviado alguma mensagem.
• Disponibilidade: Garantia do acesso a informacao ou servico, com o menor atraso
possıvel, sempre que a mesma for requisitada.
• Confidencialidade: Garantia de que o acesso a informacao e permitido apenas as
partes autorizadas.
• Integridade: Garantia de que a informacao nao sera alterada ou perdida na sua
transmissao ate o destino.
• Controle de acesso: Garantia de que somente os usuarios autenticados com per-
missao suficiente para ver, editar, remover ou adicionar algum tipo de informacao,
possam realizar essas acoes.
• Responsabilizacao (Accountability): Garantia de que todas as acoes feitas pelos
usuarios sao registradas para que sejam levadas em consideracao em decisoes futuras.
Qualquer tentativa de violar uma dessas premissas em uma aplicacao ou base de
dados, e considerada um ataque.
9
2.5.1 Vulnerabilidade e Ameaca
Vulnerabilidades sao brechas dentro de uma aplicacao que atacantes podem explorar. Por
exemplo, permitir que um par usuario-senha seja enviado na rede sem nenhum tipo de
criptografia ou existir a possibilidade de o atacante insira codigos executaveis utilizando
uma combinacao de caracteres no campo de insercao de nome de usuario, sao vulnera-
bilidades. A vulnerabilidade e interna ao sistema e a remocao da mesma depende de
atualizacao do software. Ameacas, por sua vez, sao agentes externos ao sistema que po-
dem explorar alguma vulnerabilidade para a realizacao de um ataque. Por exemplo, um
atacante mal intencionado que pretende penetrar em um sistema de monitoramento.
Vale lembrar que nao observar as boas praticas de seguranca da informacao
sao sempre as maiores vulnerabilidades, como deixar uma senha escrita em algum lugar
visıvel, ou simplesmente dizer a mesma em voz alta por algum engano. Quando um
atacante se aproveita da ingenuidade do usuario para acessar ilicitamente o sistema, ele
esta realizando um ataque de engenharia social, que e um dos mais eficientes, uma vez
que nao e necessario encontrar brechas e burlar nenhum sistema. Alem disso, o uso de
credenciais de usuarios legıtimos dificulta a previsao do ataque. Um sistema deve ser
projetado levando em consideracao que grande parte dos usuarios nao respeitarao essas
praticas, de modo que o sistema se comporte satisfatoriamente bem sob ameacas.
2.6 Projeto Cerca Inteligente de Volta Redonda
O projeto de cerca inteligente desenvolvido pela UFF para a cidade de Volta Redonda
objetiva permitir um monitoramento em tempo real dos veıculos. Os dados desse moni-
toramento sao acessados e gerenciados pelo Centro Integrado de operacoes e Seguranca
publica (CIOSP), que e o CICC de Volta Redonda.
Em linhas gerais, o projeto propoe a instalacao no perımetro da cidade de came-
ras ligadas a pontos de controle munidos de um sistema OCR. Com essa infraestrutura,
passa a ser possıvel obter as placas dos carros que estao passando pelas vias onde as
cameras estao posicionadas, a taxa de veıculos por segundo, alertas quando um veıculo
10
irregular passar por uma das cameras, armazenar o historico e exibir essas informacoes
em uma interface Web a ser disponibilizada para os funcionarios do CIOSP. Alem disso,
o projeto tambem visa prover sugestoes de movimentacao tatica das forcas armadas, esti-
mando a rota mais provavel de um veıculo uma vez feita a analise dos dados. A premissa
e que com essas informacoes, a prefeitura tenha maior controle e capacidade de tomada
de decisao sobre qualquer tipo de evento envolvendo veıculos na cidade.
2.6.1 Arquitetura da solucao de rastreamento de veıculos
O sistema proposto no projeto para a captura das placas dos veıculos usando OCR na
cerca inteligente conta com Agentes, que sao entidades de softwares autonomas com fun-
cionalidades especıficas. O conceito de agente vem do campo de inteligencia artificial
distribuıda, sendo tipicamente utilizados em cenarios cuja complexidade advem da dis-
tribuicao funcional ou fısica [10]. Os modulos utilizados na construcao da solucao sao
divididos em duas classes, Monitor e Agente. O sistema conta ainda com um banco de
dados para armazenar os dados monitorados, tanto imagens quanto textos. E importante
modularizar os servicos, que podem estar em maquinas separadas ou na mesma maquina,
pois isso permite maior flexibilidade no sistema. Quando colocados em maquinas se-
paradas, garante-se que, caso haja alguma falha, o sistema nao pare por completo. A
modularizacao precisa ser bem planejada, pois pode causar atrasos de comunicacao, por
exemplo.
A Figura ?? esquematiza o funcionamento do sistema de monitoramento de veı-
culos no projeto. O Monitor e a maquina que hospeda o servidor Web com a interface
grafica de usuario (GUI, Graphic User Interface) que sera acessada pelos usuarios uti-
lizando qualquer browser (e.g., Chrome, Firefox, Edge, Internet Explorer, Safari, Cake,
UCI, etc). O monitor realiza uma consulta no banco de dados e processa os dados para
obter informacoes como taxa de veıculos por unidade de tempo. Alem disso, acessa ban-
cos de dados externos do governo para determinar quais veıculos nao estao regulares. E
tambem o Monitor que popula o banco de dados de acordo com as escolhas do usuario.
Por exemplo, disponibiliza uma interface grafica para configurar manualmente se uma
determinada placa pertence a um carro considerado “suspeito” de acordo com os padroes
11
Figura 2.1: Diagrama dos componentes do sistema de monitoramento
do CIOSP. Por fim, o Monitor observa os pontos de controle para verificar se a conexao
permanece estavel.
Os Agentes, tambem chamados de pontos de controle, sao servicos diretamente
ligados as cameras, que processam em tempo real as imagens capturadas e mandam direto
para o banco de dados. E neles que o sistema de OCR executa para determinar as
placas dos carros que estao passando. Caso nao consigam popular a base de dados por
problemas de conexao, os Agentes mantem os dados captados em disco ate que a conexao
seja reestabelecida. A estabilidade da conexao e monitorada pelo Monitor. Cada Agente
possui de 2 ate 4 cameras ligadas. Este limite na quantidade de cameras se deve ao
processamento consumido, dado que um agente precisa filtrar cada quadro de cada camera
e registrar os dados.
Por fim o banco de dados e onde serao armazenadas todas as informacoes cole-
tadas e processadas pelo Monitor ou pelos Agentes. Tais informacoes sao classificadas em
texto e imagem, podendo os dois tipos serem armazenados juntos na mesma maquina ou
separadas em maquinas diferentes. De fato, todos os modulos do sistema (Agentes, Moni-
tor e banco de dados) sao organizados em uma ou mais maquinas conforme os requisitos
12
do usuario.
A aplicacao no Monitor e construıda utilizando o arcabouco de desenvolvimento
Web na linguagem Python, Django, junto com a interface de programacao de aplicacao
(API, Application Program Interface) do Google Maps, em Javascript.
No sistema original, mostrado na Figura 2.1 , o acesso dos usuarios e feito sem
nenhum tipo de autenticacao, utilizando uma simples chamada ao protocolo de transfe-
rencia de hiper texto (HTTP, Hiper Text Transfer Protocol). Assim, qualquer usuario
que digitar o localizador uniforme de recursos (URL, Uniform Resource Locator) da pa-
gina Web pode acessar o sistema. Nao ha nenhuma ferramenta que registre as leituras e
alteracoes realizadas, quem as fez e quando as fez. Nao existem polıticas no firewall que
decidam os enderecos a partir dos quais enderecos sao aceitas as sessoes SSH e nenhuma
interface amigavel que permita alteracoes. Os dados que trafegam na rede entre o Mo-
nitor e o usuario estao em texto claro, sem nenhum tipo de criptografia. As cameras se
comunicam com os Agentes utilizando o protocolo de fluxo em tempo real (RTSP, Real
Time Streaming Protocol), e o acesso ao banco de imagens e feito utilizando o protocolo
de transferencia de arquivos seguro (SFTP, Secure File Transfer Protocol).
Capıtulo 3
Provendo seguranca da informacao
para o projeto Cerca Inteligente
3.1 Levantamento de requisitos para a solucao pro-
posta
O CIOSP e o orgao que tem acesso ao sistema desenvolvido neste trabalho. Nao e desejavel
que outras pessoas utilizem a URL em seu navegador para verificar e alterar informacoes
por conta propria, muito menos deixar brechas para que um atacante mal intencionado
consiga ter controle sobre qualquer um dos modulos do sistema. Para garantir que eventos
que violam a confidencialidade como esse ou outro dos princıpios de seguranca da informa-
cao nao acontecam, este trabalho propoe o planejamento e a implementacao de seguranca
no projeto, visando garantir que somente quem deve possuir o acesso ao sistema de fato
o tenha.
Analisando a estrutura e utilizando como pilares de sustentacao os princıpios de
seguranca da informacao, requisitos foram levantados para implementacao de seguranca
no sistema proposto pelo projeto a fim de promover robustez a certos tipos de ataque.
13
14
Usualmente, seguranca e usabilidade sao inversamente proporcionais. Ao salvar
uma senha no navegador por exemplo, o ato de se autenticar fica muito mais rapido, mas,
em contrapartida, qualquer um com acesso aquele navegador naquela maquina tera acesso
ao sistema em questao. Com isso em mente, alguns requisitos tambem foram pensados
para aprimorar a usabilidade do sistema.
A Figura 3.1 traduz a arquitetura proposta baseada na arquitetura original do
sistema, apresentada na Figura 2.1, e nos requisitos levantados e descritos individualmente
nas secoes subsequentes. O modelo de seguranca proposto e composto por tres barreiras
de acesso. Para utilizar o sistema, e necessario passar pelo firewall, se autenticar e ter
permissoes corretas. Agora as informacoes sao criptografadas entre o servidor e o cliente,
auxiliando na manutencao da confidencialidade.
Figura 3.1: Arquitetura proposta
15
3.2 Escolha do arcabouco de desenvolvimento
Um arcabouco de desenvolvimento e uma plataforma para realizar tarefas de maneira mais
rapida e eficiente, de modo a permitir que os codigos “moldes” sejam sobrescritos para um
uso mais especıfico [11]. A utilizacao de um arcabouco de desenvolvimento amplamente
utilizado traz a vantagem de maior confiabilidade, ja que os bugs sao indicados e corrigidos
pela comunidade, garantido a remocao das principais vulnerabilidades. A desvantagem e
o tempo despendido com a curva de aprendizado para usar a ferramenta. Contudo, esse
tempo e recuperado se a plataforma simplifica e acelera a construcao de aplicacoes.
3.2.1 Interface grafica de usuario
Quase todas as aplicacoes possuem interfaces graficas de usuario (GUI, Graphical User
Interface) para simplificar o uso, tornando-o mais facil e rapido. Nos dias de hoje, e po-
pular, em ambientes corporativos, a utilizacao de interfaces graficas Web, principalmente
pela comodidade de nada precisar ser instalado, sendo necessario somente acessar pelo
browser no endereco da aplicacao. E prevista nesse projeto a implementacao de uma
interface grafica Web, visando facilitar o uso de softwares com o intermedio da GUI, de
modo que o processo realizado pelo servidor para cada acao requisitada torna-se transpa-
rente e o resultado visıvel para o usuario. Em sistemas em rede que utilizam a arquitetura
cliente-servidor, tudo que e executado no lado do cliente e chamado de frontend, e tudo
que e executado no servidor e chamado de backend. A Figura 3.2 mostra um exemplo de
codigos que sao executados no lado do cliente a esquerda e codigos que sao executados no
lado do servidor a direita.
3.2.2 Django
Para o desenvolvimento deste projeto, foi utilizado o arcabouco Django. O Django e
uma ferramenta para desenvolvimento Web, escrito na linguagem python, que acumula
um grande numero de ferramentas facilitadoras pre-implementadas. Por exemplo, ao criar
um modelo“carro”, basta executar o comando de migration para uma tabela ser criada na
16
Figura 3.2: Exemplo de frontend e backend. Adaptado de: [12]
base de dados automaticamente. E possıvel tambem usar uma interface grafica ja pronta
com formularios de visualizacao, adicao, remocao e edicao com permissoes editaveis em
poucas linhas de codigo. O Django tambem disponibiliza formas muito simples para
manipulacao de entradas do modelo na base de dados, tornando dispensavel o uso direto
de requisicoes SQL (Structured Query Language). Alem disso, o Django disponibiliza
ferramentas de debug (busca e remocao de erros no codigo) e recursos de terceiros criados
para usos mais especıficos.
O Django nao e um sistema novo. Sua criacao data de 2003 com nome herdado
do guitarrista de jazz Django Reinhardt, mostrado na Figura 3.3, conhecido como um
dos maiores musicos do seculo XX. Seus criadores foram os programadores Web Adrian
Holovaty e Simon Wilison, e atualmente encontra-se em sua versao 2.2 [13]. E conhecido
como um dos arcaboucos mais maduros na atualidade, pois possui solucoes para uma vasta
quantidade de problemas e implementacoes baseadas em feedbacks de desenvolvedores
recebidas no decorrer dos anos. O Instagram, o Mozilla e o Pinterest tem utilizado Django
por muitos anos e tem suportado picos de trafego de 50.000 requisicoes por segundo [?].
Neste trabalho, todos os backends foram construıdos na linguagem python, sempre que
possıvel utilizando ferramentas embutidas do arcabouco Django.
Arquitetura MVC (Model-View-Controller)
A arquitetura MVC e um modelo de desenvolvimento de software criada nos anos 80 por
Trygve Reenskaug [16], na Xerox Parc. Ate hoje, arcaboucos de desenvolvimento Web
17
Figura 3.3: Django Reinhardt, guitarrista de jazz do seculo XX. Fonte: [14]
Figura 3.4: Diagrama da arquitetura MVC. Adaptado de: [15].
famosos como Django e Node.js sao baseados nesta estrutura. A Figura 3.4 mostra um
diagrama com as 3 partes principais da arquitetura MVC, que sao:
• Modelo: Representa como os dados estao dispostos. Objetos do tipo modelo (
models) armazenam, consultam e editam informacoes no banco de dados.
• Visao: Representa a interface grafica vista pelo usuario. Utiliza os modelos para
permitir que o usuario realize alteracoes na base de dados pela interface.
• Controlador: Representa o processamento das requisicoes do usuario, invocando
as visoes e os modelos necessarios.
Sintetizando, o usuario manda as requisicoes para os controladores renderizarem
as visoes para exibir as informacoes contidas na base de dados manipulada pelos modelos.
As visoes podem ser usadas pelos usuarios para fazerem outras requisicoes, podendo ser
utilizadas para alteracao de informacoes da base de dados, reinvocando os controladores
18
e os modelos.
Django admin
O Django possui uma interface Web propria de administracao, amigavel e facil de cus-
tomizar. Ao adicionar novos modelos, visoes com acoes de adicao, remocao e edicao sao
criadas automaticamente, alem de ser possıvel a implementacao de acoes extras como
“Alterar Senha” sem ter que criar novos arquivos HTML. Por esse motivo a interface de
administracao do Django foi utilizada como frontend de administracao. Um exemplo de
uso do Django admin pode ser visto na Figura 3.5. Para acessar essa interface e necessario,
primeiramente, reaizar o login. A a pagina de login, que pode ser vista na Figura 3.6, em-
prega um arquivo HTML (Hypertext Markup Language) que utiliza bootstrap 4.3.1, uma
popular biblioteca de codigos CSS (Cascading Style Sheets) e Javascript para estilizacao
de paginas Web [17].
Figura 3.5: Exemplo da Interface Django admin customizada.
E possıvel sobrescrever fragmentos do codigo HTML de cada pagina, chamados
de blocos, utilizando o que a documentacao do Django [13] denomina “Template Lan-
guage”, com sintaxe muito similar a linguagem de programacao Python. Dessa forma,
alguns ajustes pequenos foram realizados na pagina de administracao de forma a deixa-la
mais amigavel para o usuario. Dentre essas modificacoes feitas, pode-se citar um popup
dentro da janela de listagem dos logs que permite alterar a idade maxima de uma entrada.
Estipular uma idade maxima para uma entrada de log e necessario porque novas entradas
19
Figura 3.6: Pagina de login.
sao inseridas constantemente, podendo atingir as limitacoes de memoria existentes.
3.3 Autenticacao
Supondo que uma pessoa va a entrada de um salao de festas e diga o seu nome para ser
conferido na lista de convidados, diz-se que esta pessoa somente se identificou. Quando
a pessoa mostra seu documento de identidade comprovando que o nome e de fato dela,
diz-se que ela se autenticou. Sintetizando, identificar-se e o ato do usuario dizer quem ele
e, e autenticar-se e confirmar a identificacao utilizando alguma prova, algo que somente
ele saiba ou possua, como uma senha.
A autenticacao e uma ferramenta usualmente necessaria em cenarios que re-
queiram confidencialidade, garantindo que apenas a entidade que possua as credenciais
necessarias possa acessar o conteudo protegido. No caso do CIOSP, para prevenir que um
cidadao comum utilize o sistema para fins pessoais, como determinar se o carro de seu
conjuge passou em determinado local em dado momento, e que usuarios mal intencionados
consigam acessar os dados privados dos cidadaos, autenticar-se antes do acesso ao sistema
de cameras e um requisito obrigatorio para o projeto.
No sistema proposto, para se identificar, e preferıvel que o usuario utilize uma
informacao unica, como seu CPF (Cadastro de Pessoa Fısica). E importante ressaltar
que nenhum usuario pode ser adicionado ao banco de dados sem que os documentos
20
comprobatorios tenham sido apresentados fisicamente ao administrador do sistema. E
necessaria a existencia de validadores de e-mail e CPF para garantir que os mesmos
existam e que nao haja nenhuma fraude. Alem disso, e interessante o usuario possuir um
campo editavel, onde informacoes pertinentes somente a ele ou ao grupo no qual pertence
sao armazenadas diretamente para uso posterior. Por exemplo, o servidor do sistema
pode mandar mensagens a todos os clientes ao mesmo tempo, mas, por alguma falha na
conexao, alguns usuarios podem nao receber. E importante armazenar essas mensagens
para retransmiti-las quando a conexao se reestabelecer.
Salvar preferencias de cada usuario, de forma que a interface grafica se encaixe
melhor dentro das suas proprias necessidades ou gostos esteticos e organizacao, e uma
boa pratica, considerando que a interface ficara mais amigavel para um maior numero
de usuarios. A Figura 3.7 mostra um exemplo de uma quantidade variada de temas que
podem ser escolhidos pelo usuario numa aplicacao.
Figura 3.7: Exemplo de 3 diferentes temas da aplicacao de e-mails Zimbra. Fonte: [18].
Apos essas definicoes, optou-se pelo uso do backend de autenticacao do Django
(django.contrib.auth) com algumas adaptacoes. Existe um objeto usuario que e facilmente
reescrito, com o passo a mais de definir nas configuracoes que o objeto modificado sera
o utilizado como padrao. Ao reescrever o modulo, foram implementadas as seguintes
adaptacoes:
• A troca dos campos padrao para campos customizados;
• A introducao de um validador customizado de CPF no lado do servidor para garantir
que o dıgito esta correto;
21
• A mudanca do campo que o usuario usa para se identificar, trocando do nome de
usuario para o CPF.
Foi tambem criada uma acao customizada que permite selecionar varios usuarios
e modificar suas senhas para uma sequencia aleatoria de 8 dıgitos com letras, numeros e
caracteres especiais. Esta sequencia e mandada para os e-mails dos usuarios afetados por
esta acao.
Por fim, e possıvel que o CIOSP possua algum servidor de autenticacao proprio,
de modo a precisar que o processo de autenticacao do sistema aja em sinergia com o
mesmo. Prevendo esta possibilidade, foi sobrescrito o objeto “formulario de autentica-
cao” do Django para que, caso seja requerido, seja implementado com a adicao de uma
unica linha no codigo do sistema. O codigo implementado no formulario esta exibido no
Apendice A.
3.3.1 Servidor de autenticacao Freeradius
O protocolo de rede RADIUS (Remote Authentication Dial In User Service) permite uma
gestao centralizada de autorizacao e autenticacao de usuarios com recursos para um vasto
numero de aplicacoes. Foi introduzido como padrao IETF (Internet Engineering Task
Force) e desenvolvido pela Livingston Entreprises Ic. no ano de 1991 [19]. O protocolo
funciona de acordo com um modelo cliente-servidor, onde o NAS (Network Access Server)
opera como cliente de um servidor RADIUS. As transacoes entre as duas partes sao
autenticadas via o uso de uma chave secreta que nunca e enviada pela rede. E extensıvel,
de forma que novos atributos podem ser acrescentados nas mensagem sem perturbar as
implementacoes existentes do protocolo [20]. A Figura 3.8 mostra a estrutura de um
pacote deste protocolo.
O campo Code e um octeto que identifica o tipo do pacote RADIUS. Se esse
valor e invalido, o pacote e descartado. O campo Identifier tambem e um octeto que
auxilia na identificacao de requisicoes e respostas, de modo que o servidor consiga detectar
requisicoes duplicadas. O campo Length possui dois octetos e indica o tamanho total do
pacote. O campo Authenticator e composto de 16 bytes e e utilizado para autenticar
22
Figura 3.8: Estrutura do pacote RADIUS. Imagem retirada da RFC2866. Fonte: [20].
mensagens entre o servidor e o cliente. Por fim o campo Attributes e variavel e contem
uma lista de zero ou mais atributos [20].
O Freeradius e um dos mais populares e amplos servidores RADIUS de codigo
aberto (open source) no mundo, sendo o unico servidor RADIUS de codigo livre que
suporta protocolo EAP (extensible Authentication Protocol) e virtualizacao. A integra-
cao com o sistema foi feita pela instalacao do servidor freeradius se comunicando com a
biblioteca pyrad, anexada ao formulario de autenticacao do Django.
O servidor freeradius nao esta sendo utilizado neste projeto, mas e mais uma
opcao conhecida para implementar autenticacao. Somente alguns testes foram realiza-
dos, integrando com sucesso o mesmo com o Django para alguns metodos existentes no
freeradius.
3.3.2 Prevencao contra ataques de forca bruta
Ataques de forca bruta se configuram quando um atacante tenta cada possibilidade de
par username-password ate que consiga penetrar no sistema. Pode ser que demore meses,
anos ou ate decadas para que o par seja descoberto, dependendo das caracterısticas da
senha que e utilizada.
Nos dias de hoje, existem formas de acelerar o metodo de forca bruta, chamados
de wordlists. Os metodos usados em ataques de forca bruta consistem em testar primei-
23
ramente senhas que sao de uso comum, como nomes, datas de aniversario e sequencias
numericas, alem de combinacoes. Alem disso, existem ferramentas que automatizam o
ataque, permitindo um maior numero de tentativas por unidade de tempo e, consequente-
mente, aumentando o risco do atacante conseguir penetrar, sugerindo que medidas devem
ser tomadas para evitar uma grande quantidade de tentativas. Ao mesmo tempo, nao
se pode tomar medidas muito drasticas como bloquear um endereco IP (Internet Pro-
tocol) por uma grande quantidade de tempo, apos uma certa quantidade de tentativas
falhas, porque humanos cometem erros e a possibilidade de um usuario legıtimo errar
suas credenciais varias vezes deve ser considerada.
Com isso em mente, uma protecao contra o ataque de forca bruta e um requisito
para aumentar a robustez do sistema. Para tanto, foi necessario o desenvolvimento de
um codigo a parte, o qual foi incorporado aos validadores do Django. Foram criados dois
models : o Black List e tentativas de login falhas. Com estes, foi implementado o seguinte
procedimento para autenticacao:
1. O atacante testa um par usuario-senha invalidos.
2. E criada uma entrada para ele em “tentativas de login falhas”.
3. Caso ultrapasse 5 tentativas, e criado uma entrada na Black List com o seu IP, e
gerado uma entrada de log da ocorrencia e todas as tentativas vindas dele serao
bloqueadas pelos proximos 5 minutos.
4. Passados os 5 minutos, ele tera direito a mais 2 tentativas.
5. Caso falhe nessas duas tentativas seu IP retorna a Black List pelo dobro do tempo
anterior.
6. Assim o ciclo se repete enquanto o atacante errar, sempre dobrando o tempo anterior.
Por exemplo, se o IP estava na Black list por 10 minutos, ele retornara e permanecera
por 20, 40, 80 para dar direito a mais 2 tentativas e assim por diante.
7. Se por ventura o atacante acertar o par, a entrada na Black List e no “tentativas de
login falhas” sumira.
24
Tambem foi adicionada uma possibilidade de bloquear determinados IPs de lo-
garem sem prazo para a saıda, a partir da modificacao de um campo que determina se a
entrada do IP na Black List e ou nao permanente. A Figura 3.9 ilustra o funcionamento
deste sistema.
O procedimento adotado e uma adaptacao do usado no MMORPG (Massive
Multiplayer Online Roaming Player Game) Tibia [21], com a diferenca de que o tempo
esperado a cada entrada na Black List cresce geometricamente na implementacao desse
projeto. Este sistema foi escolhido pela grande limitacao de tentativas do atacante. Por
exemplo, o atacante so podera fazer 32 tentativas em um perıodo de 57 dias e 34 em um
perıodo de 114 dias.
Figura 3.9: Esquema de multiplas tentativas falhas de login.
3.4 Permissoes
Poder apagar todas as informacoes coletadas e configurar o firewall de alguma maquina sao
privilegios que provavelmente nem todos os usuarios podem ter. Por exemplo, e preferıvel
que um usuario que nunca tenha configurado um firewall nao tenha permissao de faze-
lo, para evitar que seja realizado alguma operacao incorreta inadvertidamente. Por essa
razao, e uma boa pratica diferenciar as permissoes de criar, editar, visualizar e remover,
25
atribuindo-as a grupos diferentes de usuarios, de acordo com o nıvel de acesso do usuario
ao sistema e com o seu nıvel de conhecimento tecnico. Assim, a infraestrutura necessaria
para construir grupos com permissoes diferentes e um requisito, pois evita acidentes por
falta de conhecimento, contribui para confidencialidade dentro da propria organizacao e
facilita o gerenciamento.
Para cada modelo criado no Django, sao criadas permissoes automaticas para
visualizacao, edicao, adicao e remocao. As mesmas se tornam disponıveis para serem
associadas a grupos que, por sua vez sao associados a usuarios.
O nıvel do usuario depende dos grupos aos quais ele pertence e de um atributo
especial nomeado “is admin”. Se este atributo esta marcado, o usuario tem acesso irres-
trito a absolutamente tudo dentro do sistema. Caso contrario, ele acumula as permissoes
de todos os seus grupos associados. Por exemplo, o grupo A possui permissao de edi-
tar usuarios, o grupo B possui permissao de editar grupos. Um usuario que faca parte
simultaneamente dos grupos A e B possuira as permissoes de editar usuarios e editar
grupos.
3.4.1 Erro de implementacao cometido ao utilizar as ferramen-
tas prontas de permissoes do Django
Vale a pena dissertar sobre um erro cometido na utilizacao do arcabouco que consumiu
grande parte do tempo da implementacao, e como o mesmo foi mitigado.
Descricao do erro
Descrevendo primeiramente os passos para reproduzir o problema, foi usado o proprio
backend de grupos e permissoes do Django, com uma unica modificacao no nome identifi-
cador. Para este fim, primeiramente foi inserido nas configuracoes o nome do app desejado
“Django.admin.auth” como ”myAuth.apps.PermissionConfig”da seguinte forma:
26
INSTALLED_APPS = [#meus apps"firewall.apps.FirewallConfig","myAuth.apps.myAuthConfig","myAuth.apps.PermissionConfig", # Linha p r o b l e m t i c a#apps ja existentes"Django.contrib.admin","Django.contrib.contenttypes","Django.contrib.sessions","Django.contrib.messages","Django.contrib.staticfiles",
]
O modulo“myAuth.apps.PermissionConfig ”e uma extensao da classe AppConfig,
utilizado para referenciar o modulo “Django.admin.auth” da seguinte forma :
class PermissionConfig(AppConfig):name = "Django.contrib.auth"verbose_name = "2. Permissoes"
O esperado e que todas as funcionalidades fossem carregadas para uso, porem
as permissoes automaticas nao funcionaram.
Mitigacao do erro
Para mitigar esse erro, o modulo“Django.admin.auth” foi inserido diretamente e o modulo
“myAuth.apps.PermissionConfig” foi removido , da seguinte forma:
INSTALLED_APPS = [#meus apps"firewall.apps.FirewallConfig","myAuth.apps.myAuthConfig",#apps ja existentes"Django.contrib.auth", # C o r r e o realizada"Django.contrib.admin","Django.contrib.contenttypes","Django.contrib.sessions","Django.contrib.messages","Django.contrib.staticfiles",
]
Fazendo da primeira maneira, o comportamento do backend de permissoes se
torna completamente inesperado, nao respondendo como na descricao presente na docu-
mentacao oficial.
27
3.5 Sistema de auditoria (log)
O log de dados e uma forma de armazenar eventos de um software sobre seu funciona-
mento, interacoes com outros sistemas e com o proprio usuario. Acontecimentos como
adicao de informacao, remocao ou edicao da mesma, acesso a certos dados, tentativas
falhas de autenticacao e outros, sao armazenados de forma a analisa-los no futuro para
tomar decisoes e diagnosticar problemas [22].
Caso o sistema tenha sofrido uma invasao, muitas vezes, a unica forma de detec-
tar a invasao ou quando ela foi feita e fazendo uma auditoria de tudo que foi realizado em
um determinado perıodo de tempo, encontrando alteracoes nao reconhecidas por nenhum
usuario e que violam as polıticas de utilizacao do software. Nao e uma garantia de que
a penetracao sera detectada ou se o momento exato de quando houve a ocorrencia sera
descoberto, mas ainda e a forma mais efetiva de fazer esse tipo de investigacao.
Suponha agora que algum usuario fez algo indesejado no sistema e e preferıvel
retornar ao estado anterior aquela alteracao. Por exemplo, um estagiario que, por engano
ou por falta de conhecimento, insere um comando que deleta todos os dados armazenados
de clientes de uma empresa. Somente com o log pode-se determinar quem fez para punir
da forma mais adequada segundo as polıticas da organizacao, e quando fez, para assim o
backup com a data mais proxima antes do evento passar a valer como fonte oficial. Por
essas situacoes e outras, um sistema de logging e uma poderosa ferramenta, sendo um dos
requisitos deste projeto.
Para implementacao do sistema de logging, assim como nas permissoes, foi utili-
zado o modelo LogEntry ja incluso dentro do proprio Django sem grandes modificacoes.
Acoes de adicao, remocao e edicao entram na tabela de entradas de log automaticamente.
Por padrao, o modelo nao permite que entradas de log sejam deletadas. Manualmente,
foi feito com que paginas com informacao sensıvel gerem entradas de log uma vez que o
usuario faca a requisicao das mesmas pelo browser e toda vez que 5 tentativas de login
falhas sao feitas. Por fim, um modelo auxiliar foi criado para controlar a idade maxima
de uma entrada.
28
3.6 Configuracao do firewall
O firewall, ou “parede de fogo”, e analogo a uma barreira que evita o acesso de certos tipos
de pacote dentro de uma maquina. Pode ser um equipamento conectado a interface de
rede da maquina ou uma aplicacao dentro do computador, filtrando os pacotes que podem
entrar ou sair, normalmente por protocolo utilizado, endereco de entrada e endereco de
saıda. Podem ser feitas regras ainda mais complexas para realizar filtragem dependendo
da aplicacao [23].
E comum realizar a selecao de pacotes em varios nıveis, desde antes de entrar
na maquina, dentro dela, de uma aplicacao para a outra e antes de sair. Cada nıvel e
chamado de cadeia, ou chain, possuindo sua propria tabela de regras. A quantidade de
cadeias varia de acordo com o firewall utilizado.
E importante configurar o firewall da maquina para prevenir acessos nao de-
sejados. Por exemplo, neste projeto, foi configurada uma regra para so permitir que a
faixa de enderecos IP (Internet Protocol) pertencentes a polıcia de Volta Redonda possa
se conectar ao sistema. Ao mesmo tempo, e um requisito que essa configuracao possa ser
alterada de acordo com as necessidades do usuario. Para facilitar algumas dessas con-
figuracoes mais basicas, e inclusa na proposta uma interface simples de configuracao de
firewall via Web. Para tal, utiliza-se um validador customizado que trabalha em sinergia
com iptables, um utilitario que tem o objetivo de facilitar a criacao e administracao de
entradas das tabelas de firewall em um sistema Linux.
A Figura 3.10, mostra a arquitetura do iptables, ou seja, por quais cadeias o
pacote passa quando sai de uma aplicacao ate chegar na interface de rede e vice versa. A
tabela Forward controla os pacotes que entram e saem diretamente da interface de rede
sem ser recebidos por um processo, a tabela Input controla os pacotes que sao recebidas
por um processo e a tabela Output controla os que saem de um processo. E necessario ter
permissao de root (administrador da maquina) para utilizar o iptables.
Foi criada na interface grafica de administracao do Django uma forma de visu-
alizar e fazer modificacoes na configuracao de firewalls de maquinas. Entre elas, estao os
Agentes e o Monitor, referenciados na Figura ??. Para a configuracao, foi utilizada a apli-
29
Figura 3.10: Arquitetura do iptables. Fonte: [24]
cacao iptables chamada pelo Python. A aplicacao e hospedada no monitor, e e necessario
configurar o firewall tanto no Monitor quanto nos Agentes. Para configurar o Monitor,
foi utilizada a biblioteca os da linguagem python para inserir comandos via terminal, e
para os Agentes, foi utilizada a biblioteca paramiko do Python para inserir comandos em
uma conexao utilizando o protocolo SSH (Secure Shell).
3.6.1 O problema de injecao
Ao permitir de alguma forma que o usuario edite algo que envolva comandos via terminal
em um sistema qualquer, e inserida dentro do sistema uma grande vulnerabilidade que
deve ser mitigada. Por exemplo, suponha que exista um sistema hipotetico onde uma vez
que o usuario escreva suas credenciais a validacao seja feita via terminal com os seguintes
passos:
1. O usuario escreva o par usuario-senha em um formulario qualquer.
2. No servidor, a verificacao e feita via terminal com os comandos:
verificate <username> <password>
Ainda neste exemplo, vamos supor que a seguinte situacao aconteca:
1. O usuario escreva no campo de username: “; touch hacked.txt ;” e uma senha
30
qualquer.
2. No servidor, sera inserido no terminal:
verificate ; touch hacked.txt ; <password>
3. E e criado um arquivo chamado hacked.txt.
Sabendo disso, qualquer atacante tera acesso a linha de comando da maquina
onde esta rodando o sistema. Se a aplicacao tiver permissao de nıvel maximo, assim tera
o mal intencionado. Para evitar que isto aconteca, e necessario que seja feito um pro-
cesso conhecido como sanitizacao no lado do servidor, que consiste em eliminar qualquer
caractere que possa ser suspeito, tambem conhecido como caractere de “escape”.
Neste trabalho, a sanitizacao foi implementada como uma funcao para validar
as informacoes de usuario antes que essas sejam usadas no terminal:
def sanitize(text):escape_chars ="[]{}/\$~^&@?;,#!-_| ><*’()" + ’"’for escape_char in escape_chars:
text = str(text).replace(escape_char ,"")return text
Desta forma, garante-se que nenhum dos caracteres declarados possa ser conca-
tenados com strings executadas em linhas de comando.
Sao comuns questionamentos sobre como alguem mal intencionado conseguiria
fazer isso quando o usuario nao possui liberdade de escrever manualmente o valor do
campo, somente os valores selecionados. A resposta e bem simples: mudando o codigo
HTML da pagina ou via Javascript, o atacante pode alterar os campos e mandar qualquer
informacao via GET ou POST. Dessa forma, a sanitizacao se faz necessaria para prevenir
este tipo de ataque, chamado de ataque de injecao ou injection.
3.6.2 Inclusao de Redes
Primeiramente, foi criado um campo de rede, de modo que antes de ser possıvel especi-
ficar quais redes serao negadas ou nao para determinada porta, as mesmas deverao ser
registradas com uma descricao. O campo consiste no endereco IP de rede, a mascara da
31
rede em formato CIDR (Classless Inter-Domain Routing, mascara de tamanho variavel)
e a descricao com valor padrao: “Sem descricao”.
Tendo a lista de redes, duas abordagens podem ser tomadas. A primeira e realizar
a configuracao na propria maquina que roda o servico Web, nomeada de abordagem do
Monitor, e a segunda e configurar maquinas via protocolo SSH, nomeada de abordagem
dos Agentes. Estas duas abordagens serao explicadas a seguir
3.6.3 Abordagem do Monitor
So existe, necessariamente, uma entrada de modelo de monitor, pois o servidor so vai
rodar em uma unica maquina. Esse metodo e comumente chamado de singletone model,
ou seja, um model que valida somente uma unica instancia, que e suportado nativamente
pelo Django. A interface grafica acompanha, de modo que nao permite ao usuario deletar
a unica instancia existente ou adicionar novas entradas para evitar inconsistencias.
No momento em que o usuario entra no formulario do monitor para realizar a
configuracao, as informacoes sao atualizadas para evitar inconsistencias, de forma que
o sistema le as configuracoes atuais, compara com as existentes, e as altera caso seja
necessario. Se linhas de permissao de SSH forem encontradas na tabela iptables e as
redes nunca foram cadastradas, sao criadas estas redes com descricao: “Autodiscovered”.
Alem disso, o usuario tera acesso, se possuir permissao, a um campo mostrando as linhas
iptables presentes no momento em que a pagina for carregada, para analisar por conta
propria, caso queira. As informacoes presentes disponıveis para modificacao pelo usuario
neste sistema sao:
1. Porta do Servico SSH.
2. De quais redes pode vir uma requisicao de conexao SSH.
3. Rejeicao ou nao de pacotes de protocolo ICMP.
Foram escolhidos para a configuracao estes campos para limitar o acesso aos
agentes e ao monitor via SSH de maneira mais facil, buscando mitigar possıveis ataques
32
envolvendo este protocolo. Dar a opcao de desabilitar o ICMP tambem e importante pelos
ataques de negacao de servico existentes nos dias de hoje que o utilizam, por exemplo o
Ping Flood, que consiste numa grande quantidade de requisicoes em um curto perıodo
de tempo para sobrecarregar a aplicacao. Ao clicar em salvar, o formulario chama uma
funcao personalizada que compara o estado atual com o estado anterior, recupera as linhas
iptables atuais e converte do tipo string para dicionario para fins de filtragem. Essa funcao
personalizada, primeiramente, verifica a porta SSH antiga e a porta atual. Caso sejam
diferentes, o programa abre o arquivo no caminho “/etc/ssh/sshd config” e, como segunda
tentativa, o arquivo “/etc/ssh/ssh config”. Na sequencia, o programa busca a string “Port
” e altera essa linha para “Port <porta ssh escolhida>”. Depois, verifica todas as entradas
com protocolo TCP e porta antiga SSH na tabela de firewall, deleta as mesmas e reinsere
com a porta mais nova.
Uma vez que a porta e alterada, sao deletadas as linhas que nao estao presentes
no estado atual que constam no estado anterior, sempre do numero de linha mais alto
para o mais baixo para garantir os ındices. Por exemplo, suponha que haja uma tabela
com 16 linhas e a de numero 15 deve ser deletada, feita a delecao a linha de numero 16
ganha o numero 15, herdando o ındice da linha antecessora. Por causa deste fato, caso as
linhas 1, 4 e 7 precisem ser deletadas, a ordem de delecao deve ser 7, 4 e 1, ou os ındices
serao trocados e linhas serao removidas de maneira erronea. Por ultimo, sao inseridas
as linhas que estao no estado atual e que nao estao no estado anterior, ja com a porta
SSH mais nova. O usuario so pode inserir redes na tabela iptables que ele ja cadastrou
anteriormente na lista de redes.
3.6.4 Abordagem dos Agentes
Diferentemente do monitor, que e apenas um, podem existir diversos agentes na rede.
Assim, ha um processo especial para visualizacao, adicao e edicao das regras de firewall
e de comandos para cada agente. Foi criado um formulario de insercao para adicao de
novos agentes no sistema, que possui um campo para colocar a senha de root da maquina
que esta sendo adicionada. Esta senha nao e salva dentro do banco de dados em nenhum
momento, sendo utilizada apenas para salvar a chave publica do Monitor nos Agentes,
33
e, assim, permitir a conexao automatica entre Monitor e Agente sem a necessidade de se
digitar ou ler a senha de um arquivo. O processo de insercao de um Agente retorna para
o usuario um feedback de sucesso se a chave publica do Monitor for salva com exito no
Agente.
Se antes de alterar no programa, o usuario fez alteracoes nas tabelas iptables
manualmente, a informacao na base de dados nao ira condizer com a realidade. Por esse
motivo, toda vez que e aberta a pagina HTML para visualizacao do Agente, o sistema abre
uma conexao SSH com a maquina pelo IP configurado, verifica e interpreta as linhas e
atualiza a base de dados de acordo com elas. Caso ocorra algum erro durante a atualizacao,
uma mensagem de alerta e enviada para o usuario, especificando que houve um erro
durante a atualizacao.
O processo de edicao e essencialmente o mesmo do monitor, com a ligeira dife-
renca de que testes de conexao sao realizados antes e, se falharem, retornam um erro de
validacao, especificando que nao foi possıvel estabelecer conexao.
Foi utilizada a biblioteca paramiko da linguagem Python para a realizacao de
conexoes SSH. A tecnica utilizada para a edicao das linhas foi exatamente o mesmo
descrito para a edicao do monitor.
3.7 Portabilidade da instalacao usando conteineres
Conteineres permitem a um desenvolvedor “embalar” uma aplicacao e todas as suas de-
pendencias em um unico pacote, garantindo que funcione em qualquer outra maquina
mesmo com configuracoes e sistemas operacionais completamente diferentes. Sao muito
usados para fazer instalacao em massa de alguma aplicacao e para garantir compatibili-
dade mesmo com atualizacoes na maquina hospedeira com o passar do tempo.
Os conteineres sao similares a maquinas virtuais, mas nao precisam de hipervi-
sores. Compartilham recursos com a maquina hospedeira sempre que possıvel, garantindo
um maior desempenho. A Figura 3.11 apresenta um esquema contrastando as diferencas
entre o funcionamento de um conteiner e de uma maquina virtual. Enquanto um contei-
34
ner consiste basicamente em um conjunto de processos que sao separados dos outros mas
compartilham o sistema operacional, a maquina virtual possui um sistema operacional
separado, com o hardware virtualizado [25] .
Figura 3.11: Comparacao de um conteiner Docker e uma maquina virtual. Fonte: [26].
Varias maquinas poderao servir como Agentes, sendo que esse numero tende a
crescer com o uso do sistema. Para facilitar e garantir a instalacao de todas as dependen-
cias das aplicacoes dos Agentes, e extremamente util a utilizacao de conteineres, evitando
erros de instalacao e de compatibilidade com outros sistemas instalados na maquina.
3.7.1 Docker vs. LXD
Duas distribuicoes principais de conteiners sao o Docker e o LXD. Ambos sao tipos de
conteineres e podem ser utilizados para uma infinidade de solucoes. A decisao de um em
detrimento do outro depende das especificacoes do projeto.
O Docker e um conteiner especializado em implantacao de aplicacoes, construıdo
com a linguagem de alto desempenho Go, criada pela Google. Possui a arquitetura mais
simplista em comparacao com um conteiner LXD e e mais popular entre os desenvolve-
dores. Por essa mesma razao, nao e recomendado utilizar mais de uma aplicacao dentro
de um mesmo conteiner Docker. O LXD e especializado em implantacao de maquinas
35
virtuais Linux completas. E bem mais equipado e bem mais parecido com um ambiente
de um sistema operacional. Dentro de um conteiner deste tipo, e possıvel rodar multiplos
conteineres docker. O LXD possui um melhor suporte para networking que o docker.
Por exemplo, um docker nao responde a ICMP (Internet Control Message Protocol). Em
suma, ganha em escalabilidade e robustez.
Embora o LXD seja muito mais robusto, a intencao e colocar somente uma
aplicacao por maquina, justamente o princıpio de utilizacao do Docker. Assim, optou-se
pela solucao mais leve e simples apresentada pelo Docker.
3.8 Servidor Web
Para o projeto sair da etapa desenvolvimento e partir para a etapa de uso, especialmente
feito usando o arcabouco Django, existem alguns passos a serem seguidos. Primeiramente,
o codigo do Django e desenvolvido em um servidor Web para desenvolvimento. Assim,
e necessario alterar o servidor que vai rodar a aplicacao, tendo sido utilizado o servidor
Apache para uso em producao.
Para realizar a configuracao necessaria em um sistema operacional Ubuntu, pri-
meiramente, e criado um arquivo de configuracao, com o nome “cercainteligente site.conf”
que sobrescrevera o arquivo “/etc/apache2/sites-available/000-default.conf”. Nele, todas
as informacoes necessarias para o Apache rodar a aplicacao serao inseridas. Comecando
pela raiz do Apache, ou seja, a partir de onde os clientes poderao ter acesso, introduz-se
a linha “DocumentRoot /var/www/html/” no bloco <VirtualHost *:80>. E necessario
tambem ter um caminho para os arquivos estaticos, ou seja, as imagens, o estilo via
CSS e o Javascript. Para tal, e incluida a linha “Alias /static “/var/www/html/cercain-
teligente/static””. Sem ela, o estilo do site de administracao do Django nao podera ser
carregado.
Por fim, o caminho para o arquivo“wsgi.py”e adicionado usando a linha“WSGIS-
criptAlias / /var/www/html/cercainteligente/cercainteligente/wsgi.py”. O WSGI (Web
Server Gateway Interface) e a especificacao que descreve como um servidor Web se co-
36
munica com as suas aplicacoes e como essas aplicacoes podem se unir para processar uma
dada requisicao [27], que ja vem disponıvel ao inicializar um projeto no Django.
Figura 3.12: Configuracao do apache.
A Figura 3.12 demonstra como fica o arquivo de configuracao para que o Apache
funcione corretamente para uma aplicacao Web feita em Django.
E necessario tambem adicionar uma linha no arquivo “settings.py”, que e o ar-
quivo onde ficam as configuracoes gerais no arcabouco Django, especificando onde fica os
arquivos estaticos, com o conteudo “STATIC ROOT = ’/var/www/html/cercainteligen-
te/static’ ” e rodar o comando “python3 manage.py collectstatic” no terminal.
A aplicacao e colocada dentro de conteineres Linux, com sistema operacional
Ubuntu 18.04, ja que todos os testes foram realizados com esse sistema operacional. Para
isso, modifica-se um conteiner Docker do usuario ramkulkarni1 [28] do github para funci-
onar na porta 443. Alem disso, sao baixados os pacotes necessarios para o funcionamento
do sistema.
3.8.1 Criptografia do Trafego
Suponha um caso onde alguem mal intencionado consegue capturar o trafego de outros
usuarios no transito da rede. Essa pessoa mal intencionada deseja ver o conteudo da
conversacao, mas muito provavelmente, se houver informacao sensıvel trafegando pela
rede, as partes nao terao intencao alguma de que terceiros acessem seus dados e muito
menos tenham a chance de adultera-los no meio do caminho.
37
Figura 3.13: Esquematizacao de um ataque MITM (Man In The Middle). Fonte: [29]
O ato de acessar o dado de terceiros durante o transito dos dados na rede e
conhecido como ataque do tipo MITM (Man In The Middle), e esta esquematizado na
Figura 3.13. A solucao conhecida para evitar esse ataque e criptografia aliada a uma
autenticacao forte, ou seja, embaralhar e substituir uma sequencia de bits por outra de
modo que somente os lados que estao ativos na conversacao e possuem a chave para
desfazer a criptografia possam recuperar a informacao. Em sistemas Web, e padrao o
uso do protocolo SSL (Secure Socket Layer), dado que varias aplicacoes nos dias de hoje
lidam com esse protocolo nativamente. Por essa razao, o uso do SSL e proposto para o
projeto.
A implementacao e realizada por uma configuracao feita no Apache2 que nao
bloqueia efetivamente o protocolo HTTP na porta 80 (porta usada por padrao pelo pro-
tocolo HTTP), mas sim recebe as requisicoes e redireciona automaticamente para a porta
443, onde e normalmente utilizado o protocolo HTTPS (Hyper Text Transfer Protocol
Secure). Isto e feito porque os browsers normalmente utilizam HTTP quando o usuario
digita o endereco sem especificar o protocolo.
Capıtulo 4
Outras contribuicoes
Alem da parte de seguranca, houve contribuicoes em outras ramificacoes do projeto, entre
elas, formas de analisar os dados recebidos dos veıculos que passam, criando meios de
rapida visualizacao e geracao de relatorios para o usuario final.
4.1 O modulo de tracing
Nesse modulo reside todo o processo de como os dados coletados sao vistos e filtrados,
de forma a deixar a visibilidade de qualquer informacao util de maneira rapida e facil.
Criando-se um frontend em HTML5, mostrado na Figura 4.1, expondo na maior parte
da tela um mapa da cidade de Volta Redonda, gerado com o auxılio da API do Google.
Mais especificamente, a Maps JavaScript API e utilizada para mudar a posicao do mapa
e criar marcadores que ativam acoes ao ocorrer algum evento, como o clique do mouse ou
passar o mouse por cima de um determinado objeto.
Ao passar o mouse por cima de um Agente, surge uma pequena janela de infor-
macao para disponibilizacao de alguns dados, como taxa de carros por minuto, segundo
ou outra unidade de tempo escolhida. Alem disso, ainda no contexto das acoes tomadas
no evento de passar o mouse, o cliente, via javascript, realiza consultas a cada segundo na
39
base de dados para atualizar as informacoes dentro da janela. Ao tirar o mouse, a janela
desaparece e o cliente para de fazer consultas. Isto foi possıvel pela criacao de uma visao
que recebe requisicoes pela URL e retorna respostas em formato JSON (JavaScript Object
Notation), interpretadas e disponibilizadas na tela do usuario pelo Javascript no lado do
cliente.
Figura 4.1: Demonstracao da primeira pagina criada no modulo de tracing.
A esquerda da tela, e apresentada uma lista com todas as placas de veıculos
cadastradas, com possibilidade de pesquisa pelo nome da placa. Uma vez clicado em uma
placa qualquer, sao mostradas informacoes mais detalhadas sobre o veıculo e um link para
ver o historico completo do mesmo, alem de aumentar o zoom do mapa centralizando no
ultimo ponto de controle onde aquela placa foi detectada.
Para marcar se um carro e considerado suspeito ou nao, dois fatores sao levados
em consideracao: se o mesmo esta marcado como irregular no banco de dados da polıcia,
ou se o comportamento analisado uma vez que os dados sao coletados e considerado
atıpico, como passar por pontos de controle proximos grande quantidade de vezes em um
curto perıodo de tempo. Essa analise sera feita pelo modulo de inteligencia do projeto,
que esta previsto de ser implementato mas nao neste trabalho.
E possıvel gerar graficos no formato de pizza ou de linhas com as mais diferentes
40
Figura 4.2: Demonstracao da segunda pagina criada no modulo de tracing.
informacoes, como a evolucao media da quantidade de carros por perıodo de tempo. Alem
disso, existe a possibilidade exportar esses dados para planilhas no formato xlsx utilizando
a biblioteca openpyxl, para manipulacao em softwares como o Excel.
Capıtulo 5
Resultados e discussoes
Feitas todas as implementacoes, sao necessarios testes para garantir que tudo esteja fun-
cionando corretamente. Como resultados deste trabalho, imagens retratando respostas do
sistema as acoes do usuario serao mostradas para demonstrar, na pratica, os elementos
descritos nos capıtulos anteriores.
5.1 Demonstracao de bloqueio ao ataque de forca
bruta
Ao errar o par usuario-senha ate quatro vezes, o formulario de login retorna para o usuario
a mensagem mostrada na Figura 5.1, informando o erro. Ja se o usuario errar mais vezes
que esse limite, tera de esperar o tempo necessario de quatro minutos, retratado na Figura
5.2, entrara na Black List e ficara registrada uma entrada de log deste acontecimento
exatamente como na Figura 5.3.
41
42
Figura 5.1: Mensagem ao errar as credenciais de autenticacao ate quatro vezes.
Figura 5.2: Mensagem apos quatro falhas.
Figura 5.3: Entrada na tabela de log na black list.
43
5.2 Validador de campos usuario
O exemplo da Figura 5.4 demonstra o funcionamento dos validadores que se ativam ao
tentar adicionar um novo usuario para ter acesso a aplicacao. Nesse caso, o CPF digitado
nao e valido, assim como o e-mail.
Figura 5.4: Erro de adicao de usuario.
5.3 Demonstracao da edicao de firewall via GUI
O primeiro passo e adicionar uma maquina na base de dados do sistema, nomeada agent.
Uma vez que os campos do formulario sao enviados, e verificado pelos validadores se foi
possıvel estabelecer a conexao com o agent e instalar a chave publica SSH, caso nao, e
retornado um erro como mostrado na Figura 5.5.
Antes de adicionar ou remover redes nas linhas das tabelas iptables, como ja
foi dito, e necessario adicionar estas redes no banco de dados da aplicacao. Para tal
e necessario que o IP inserido seja considerado um endereco de rede para a mascara
44
Figura 5.5: Erro de adicao de agent.
selecionada. A Figura 5.6 demonstra como os validadores retornam os erros para o usuario,
uma vez que o mesmo enviou os dados, nesse caso porque o endereco de IP escolhido nao
e valido para a mascara escolhida. A Figura 5.7 mostra a resposta de uma adicao de um
agent com sucesso.
Figura 5.6: Erro de adicao de rede no sistema.
Adicionados os IPs e o agent e abrindo o formulario de edicao, a aplicacao realiza
testes de conexao e tenta atualizar as informacoes em tela. Caso falhe, informa ao usuario
como exibido na Figura 5.8. Com conexao estabelecida, e fazendo as alteracoes propostas
na Figura 5.9, com sucesso, na interface Web sao mostradas as linhas da tabela iptables
na aplicacao como na Figura 5.10.
45
Figura 5.7: Adicao de rede no sistema com exito.
Figura 5.8: Alerta de falta de conexao.
5.4 Resposta a falha em conexoes persistentes
Nas visoes do modulo de tracing, o usuario nao precisa recarregar a pagina para obter
os dados mais recentes, pois existe uma conexao persistente com o servidor que garante
que atualizacoes cheguem a pagina HTML vista. Contudo, e possıvel que a conexao
sofra alguma falha, e embora servidor e cliente reconectem automaticamente, pode ser
que mensagens enviadas possam nao chegar ao destino. Para evitar que informacoes nao
cheguem a tela dos usuarios, existe uma notificacao que a conexao persistente falhou com
um botao de recarregar a pagina, mostrada na Figura 5.11.
46
Figura 5.9: Formulario proposto para configuracao simples do firewall.
Figura 5.10: Tabela iptables mostrada no formulario.
Figura 5.11: Alerta de falha na conexao.
Capıtulo 6
Conclusao e sugestoes para trabalhos
futuros
Este projeto implementou camadas no sistema de cerca inteligente que esta sendo de-
senvolvido pela UFF para a prefeitura de Volta Redonda, Rio de Janeiro. O objetivo
era agregar seguranca ao sistema, que havia sido inicialmente projetado sem considerar
nenhum requisito de seguranca. Para tanto, foram implementadas as camadas de auten-
ticacao, interface grafica de configuracao de firewall, configuracao do servidor Web para
comunicacao utilizando criptografia SSL. Alem disso, este trabalho contribuiu para me-
lhorar a interface de usuario. Os codigos foram inseridos dentro de conteineres Docker
para facilitar sua instalacao em outras maquinas.
Os resultados obtidos durante o desenvolvimento foram bastante satisfatorios,
uma vez que, no final, tudo funcionou bem e foi possıvel adquirir conhecimento em di-
ferentes ferramentas muito uteis, como o Django. Fazendo ainda uma comparacao no
tempo de desenvolvimento de um software com interface grafica Web do zero e utilizando
um arcabouco, a velocidade e muito maior e a susceptibilidade a erros e muito menor,
dado que o sistema ja esta ha algum tempo recebendo atualizacoes para aprimorar o fun-
cionamento e remover possıveis vulnerabilidades. Tambem vale a pena mencionar que os
erros cometidos durante o desenvolvimento do projeto contribuıram para descobrir como
48
realizar determinados processos utilizando as melhores praticas, tanto para benefıcio do
desenvolvedor quanto para o usuario. Ainda neste projeto, e necessario realizar estudos
sobre aprendizado de maquina para construir o modulo de inteligencia, alem de contribuir
em outras partes do sistema que demandem.
Para o futuro, pode ser sugerida a implementacao de seguranca na informacao
em outras camadas do modelo OSI (Open System Interconnection), que nao a aplicacao,
alem do desenvolvimento de um sistema de deteccao de intrusao (IDS, Instrusion Detection
System). Tambem o estudo sobre orquestradores de conteineres para verificar se sao uteis
ao sistema, deixar mais robusta a interface de configuracao de firewall e a criar mais
arquivos CSS para permitir mais variacoes de temas aos usuarios.
Bibliografia
[1] LEC. Seguranca da informacao nas cidades inteligen-
tes. Disponıvel em: <http://www.lecnews.com.br/blog/
seguranca-da-informacao-nas-cidades-inteligentes/>. Acesso em: 9 de
abril de 2019.
[2] Jason Andress. The basics of information security: understanding the fundamentals
of InfoSec in theory and practice. Syngress, 2014.
[3] Tan Yigitcanlar, Md. Kamruzzaman, Laurie Buys, Giuseppe Ioppolo, Jamile
Sabatini-Marques, Eduardo Moreira da Costa, and JinHyo Joseph Yun. Unders-
tanding ‘smart cities’: Intertwining development drivers with desired outcomes in a
multidimensional framework. Cities, 81:145 – 160, 2018.
[4] Elvira Ismagilova, Laurie Hughes, Yogesh K. Dwivedi, and K. Ravi Raman. Smart ci-
ties: Advances in research—an information systems perspective. International Jour-
nal of Information Management, 47:88 – 100, 2019.
[5] VivaDecora. What is a software framework? Disponıvel em: <https://www.
vivadecora.com.br/pro/curiosidades/cidades-inteligentes/>. Acesso em: 9
de abril de 2019.
[6] BBC. Safe cities: Using smart tech for public security. Disponı-
vel em: <http://www.bbc.com/future/bespoke/specials/connected-world/
government.html>. Acesso em: 9 de abril de 2019.
[7] Planejamento estrategico de seguranca publica e de defesa para a copa do mundo
49
50
FIFA Brasil 2014. Technical report.
[8] Eduardo Cerqueira Batitucci Philipp Augusto Krammer Soares. O centro integrado
de comando e controle: ferramenta de coordenacao, integracao e planejamento na
defesa social. Technical report, 8 2017.
[9] Nicom. Optical character recognition (ocr) – how it works. Disponıvel em: <https:
//www.nicomsoft.com/optical-character-recognition-ocr-how-it-works/>.
Acesso em: 9 de abril de 2019.
[10] Geeks for Geeks. Agents in artificial intelligence. Disponıvel em: <https://www.
geeksforgeeks.org/agents-artificial-intelligence/>. Acesso em: 9 de abril
de 2019.
[11] Stack Overflow. What is a software framework? Disponıvel em: <https:
//stackoverflow.com/questions/2964140/what-is-a-software-framework>.
Acesso em: 9 de abril de 2019.
[12] Agira. How to become a full stack web developer. Disponıvel em: <https://www.
agiratech.com/how-to-become-a-full-stack-web-developer/>. Acesso em: 9
de abril de 2019.
[13] Django. Django documentation 2.1. Disponıvel em: <https://docs.
djangoproject.com/en/2.1/>. Acesso em: 9 de abril de 2019.
[14] Radio Camara. O som do guitarrista Django Reinhardt - bloco 2. Disponı-
vel em: <https://www2.camara.leg.br/camaranoticias/radio/materias/
ESQUINA-DO-JAZZ/551767-O-SOM-DO-GUITARRISTA-DJANGO-REINHARDT-BLOCO-2.
html>. Acesso em: 9 de abril de 2019.
[15] Wikipedia. MVC. Disponıvel em: <https://pt.wikipedia.org/wiki/MVC>.
Acesso em: 9 de abril de 2019.
[16] Heim. Mvc. Disponıvel em: <http://heim.ifi.uio.no/~trygver/themes/mvc/
mvc-index.html>. Acesso em: 9 de abril de 2019.
[17] Get Bootstrap. Bootstrap. Disponıvel em: <https://getbootstrap.com/>. Acesso
51
em: 9 de abril de 2019.
[18] Zimbra. Disponıvel em: <https://www.zimbra.com/>. Acesso em: 9 de abril de
2019.
[19] LLC Interlink Networks. The Beginnings and History of RADIUS. 2006.
[20] C. Rigney. Radius accounting. RFC 2866, RFC Editor, June 2000. http://www.
rfc-editor.org/rfc/rfc2866.txt.
[21] Tibia. news. Disponıvel em: <https://www.tibia.com/news/?subtopic=
latestnews>. Acesso em: 9 de abril de 2019.
[22] Strong Security. Voce sabe o que e o log de dados? entenda
sua importancia. Disponıvel em: <https://www.strongsecurity.com.br/
voce-sabe-o-que-e-log-de-dados-entenda-sua-importancia/>. Acesso em: 9
de abril de 2019.
[23] Tecmundo. O que e firewall? Disponıvel em: <https://www.tecmundo.com.br/
firewall/182-o-que-e-firewall-.htm>. Acesso em: 9 de abril de 2019.
[24] Boson Treinamentos. Firewall iptables no linux – parte 01: Nocoes
basicas. Disponıvel em: <http://www.bosontreinamentos.com.br/linux/
firewall-iptables-no-linux-parte-01-nocoes-basicas/>. Acesso em: 9 de
abril de 2019.
[25] Ajeet Singh Raina. Docker vs. vm – who wins? Dis-
ponıvel em: <https://devopsconference.de/blog/docker/
docker-vs-virtual-machine-where-are-the-differences/>. Acesso em:
9 de abril de 2019.
[26] Accenture. Evolution of linux containerization helped in simplifying devops
using docker. Disponıvel em: <hhttps://www.accenture.com/us-en/blogs/
blogs-reshma-shinde-docker-containerization-devops>. Acesso em: 9 de
abril de 2019.
[27] WSGI Documentation. What is WSGI? Disponıvel em: <https://wsgi.
52
readthedocs.io/en/latest/what.html>. Acesso em: 9 de abril de 2019.
[28] Github. django-apache2-docker. Disponıvel em: <https://github.com/
ramkulkarni1/django-apache2-docker>. Acesso em: 9 de abril de 2019.
[29] Secure Box. What is man-in-the-middle attack? Disponıvel em: <https:
//securebox.comodo.com/ssl-sniffing/man-in-the-middle-attack/>. Acesso
em: 9 de abril de 2019.
Apendice A
Formulario customizado de
autenticacao
# AUTH BLOCK FUNCTIONSdef term_test(initial , block_time):
if initial + timedelta(minutes=block_time) > now():return initial + timedelta(minutes=block_time) - now()
else:return False
def was_in_black_list(ip):test = BlackList.objects.filter(ip=ip)if not test:
return Falseelse:
return True
def is_in_black_list(ip):if was_in_black_list(ip):
obj = BlackList.objects.get(ip=ip)if obj.permanent:
return Trueif term_test(obj.date , obj.term):
return term_test(obj.date , obj.term).seconds // 60else:
if not obj.expired:obj.expired = Trueobj.save()LoginAttempts.objects.filter(ip=ip).update(blockCount=0)
return False
else:return False
54
def punish(ip):if not was_in_black_list(ip):
entry = BlackList(ip=ip,term=5,
)entry.save()
else:entry=BlackList.objects.get(ip=ip)entry.term = 2*entry.termentry.expired = Falseentry.save()
def attempt_limit(ip):test = LoginAttempts.objects.filter(ip=ip)if not test:
return Falseelse:
if was_in_black_list(ip): max_attempts = 2else: max_attempts = 2if test[0].blockCount >= max_attempts:
punish(ip)test.update(blockCount=0)return True
else:return False
# Custom Formclass MyAuthenticationForm(AuthenticationForm):
def clean(self):username = self.cleaned_data.get(’username ’)password = self.cleaned_data.get(’password ’)ip = self.request.META["REMOTE_ADDR"]
#blackList checkif is_in_black_list(ip):
lasts = is_in_black_list(ip)raise forms.ValidationError(" V o c excedeu o limite de
tentativas permitidas ,tente de novo emaproximadamente " + str(lasts) + " minutos")
#attempts checkif attempt_limit(ip):
LogEntry.objects.log_action(user_id=1,content_type_id=get_content_type_for_model(LoginAttempts
).pk,object_id=0,action_flag=ADDITION ,object_repr="Multiplas tentativas de login Falhas",change_message=’{quantidade :"’ + str(LoginAttempts.
objects.get(ip=ip).attempts) + ’",ip:"’+ ip + ’"}’
)raise forms.ValidationError(" V o c excedeu o limite de
tentativas permitidas.tente de novo em algunsminutos")
55
if username and password:self.user_cache = authenticate(username=username ,
password=password)if self.user_cache is None:
# custom beginif not LoginAttempts.objects.filter(ip = self.request.
META["REMOTE_ADDR"]):
entry = LoginAttempts(ip = self.request.META["REMOTE_ADDR"],attempts=1,blockCount=1,
)entry.save()
else:entry = LoginAttempts.objects.get(ip=self.request.
META["REMOTE_ADDR"])
entry.attempts=entry.attempts + 1entry.blockCount=entry.blockCount + 1entry.save()
# custom endraise forms.ValidationError(
self.error_messages[’invalid_login ’],code=’invalid_login ’,params={’username ’: self.username_field.verbose_name
},)
else:LoginAttempts.objects.filter(ip=ip).delete ()BlackList.objects.filter(ip=ip).delete ()self.confirm_login_allowed(self.user_cache)
Apendice B
Conversor de linhas iptables de
string para formato de dicionario
def get_lineDict(conn):lines = get_lines_ssh(conn)line_dict = dict()current_chain = ""for line in lines:
if len(line.split()) > 1:if line.split()[0] == "Chain":
current_chain = line.split()[1]line_dict[current_chain] = []
if line.split()[0].isnumeric ():num = line.split()[0]target = line.split()[1]prot = line.split()[2]opt = line.split()[3]source = line.split()[4]
dicio = dict()
has_dpt = Falsefor word in line.split():
if word.count("dpt:"):dicio["dpt"] = wordhas_dpt = True
if not has_dpt:dicio["dpt"] = ""
dicio["num"] = numdicio["target"] = targetdicio["prot"] = protdicio["opt"] = optdicio["source"] = sourceline_dict[current_chain].append(dicio)
return line_dict
Apendice C
Detector de mudancas nas linhas do
firewall
def agent_detectChanges(old , new , form):#Getting old and new ssh lists
conn = connect(old.ip, port=old.sshPort)old_sshs = list()new_sshs = list()for ip in form.cleaned_data["ssh"]:
new_sshs.append(ip.get_nets ())for ip in old.ssh.all():
old_sshs.append(ip.get_nets ())
#detecting ICMP#print("icmp: ", old.icmp , new.icmp)if old.icmp != new.icmp:
if new.icmp:configureICMP(conn , "Delete")configureICMP(conn , "add", "ACCEPT")
else:configureICMP(conn , "Delete")configureICMP(conn , "add", "DROP")
# add if not existfor source in old_sshs:
if not ThisLineExists(conn , old.sshPort , source=source):addThisLine(conn , sshPort=new.sshPort , source=source)
#changing SSH portif old.sshPort != new.sshPort:
for source in old_sshs:addThisLine(conn , new.sshPort , source)deleteThisLine(conn , sshPort=old.sshPort , source=source , dpt
="dpt:"+str(old.sshPort))
changeSSHPort(conn , new.sshPort)
58
#Changing SSHfor ip in old_sshs:
if ip not in new_sshs:deleteThisLine(conn , sshPort=new.sshPort , source=ip, dpt="
dpt:ssh")
for ip in new_sshs:if ip not in old_sshs:
addThisLine(conn , sshPort=new.sshPort , source=ip)SSHSave(conn)