- LabEPI

Transcrição

- LabEPI

UNIVERSIDADE FEDERAL DO RIO GRANDE DO NORTE
Universidade Federal do Rio Grande do Norte – UFRN
Centro de Ensino Superior do Seridó – CERES
Departamento de Computação e Tecnologia – DCT
Bacharelado em Sistemas de Informação – BSI
Descoberta de infraestrutura e serviços de rede
utilizando dispositivos móveis
Marcos Túlio de Lima Vianna
Orientador: Prof. Dr. João Paulo de Souza Medeiros
Trabalho de Conclusão de Curso apresentado ao Curso de Bacharelado em Sistemas de Informação como parte dos requisitos para obtenção do tı́tulo de Bacharel em
Sistemas de Informação.
Laboratório de Elementos do Processamento da Informação – LabEPI
Caicó, RN, 13 de janeiro de 2016
Catalogação da Publicação na Fonte
Universidade Federal do Rio Grande do Norte - UFRN
Sistema de Bibliotecas - SISBI
Vianna, Marcos Túlio de Lima.
Descoberta de infraestrutura e serviços de rede utilizando dispositivos móveis.
/ Marcos Túlio de Lima Vianna. – Caicó, 2016.
78f: il.
Orientador : João Paulo de Souza Medeiros Dr.
Monografia (Bacharel em Sistemas de Informação) Universidade Federal do
Rio Grande do Norte. Centro de Ensino Superior do Seridó - Campus Caicó.
1. Descoberta de serviços e infraestrutura. 2. Dispositivos móveis. 3. Redes
de Computadores. I. Medeiros, João Paulo de Souza. II. Tı́tulo.
Descoberta de infraestrutura e serviços de rede
utilizando dispositivos móveis
Marcos Túlio de Lima Vianna
Monografia aprovada em 19 de dezembro pela banca examinadora composta pelos
seguintes membros:
Prof. Dr. João Paulo de Souza Medeiros (orientador) . . . . . . . . . . . . DCT/UFRN
Prof. MSc. João Batista Borges Neto . . . . . . . . . . . . . . . . . . . . . . . . . . . . DCT/UFRN
Prof. MSc. Luiz Paulo de Souza Medeiros . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . IFRN
Agradecimentos
Uma das maiores virtudes de um ser humano é o reconhecimento e certamente estes
parágrafos não irão acolher todas as pessoas que fizeram parte dessa importante conquista.
Portanto, desde já peço desculpas aquelas que não estão presentes entre essas palavras,
mas podem ter certeza que fazem parte do meu pensamento e de minha gratidão.
Agradeço a Deus pelo discernimento, força e saúde para superar as dificuldades.
Ao meu pai Jorge Alves Vianna pelo apoio incondicional em todos os momentos da minha
vida, por ter me tornado um homem de bem, por ser meu melhor amigo, pelas caronas pra
Caicó e pelo sacrifı́cio diário para que eu pudesse alcançar meus objetivos. Tenho orgulho
de ser filho. A minha mãinha Maria Aparecida de Lima Vianna, principal responsável por
essa conquista, sem você eu não estaria onde estou. Muito obrigado por todo tempo que
você cuidou de mim, pelo conforto nos momentos de angustia, por me passar toda a sua
sabedoria e destemor mesmo em situações difı́ceis. Tenho a certeza de que no lugar mais
puro desta terra a senhora me observa e cuida de mim como se estivesse ao meu lado.
Enfim, sou grato por investirem em mim e me proporcionarem tudo que precisei e por ter
me tornado um reflexo de vocês. Eu os Amo.
A minha irmã Tamara de Lima Vianna por todo o “carinho” e companheirismo transmitidos. Você é um dos motivos que fazem permanecer nessa caminhada. Te amo, minha
irmã.
A minha namorada Mayonara Fabı́ola pela paciência, afeto e compreensão nos momentos
tristes e pela companhia, divertimento e tranquilidade nos bons momentos. Amo você.
A Maycon, Dênis, Ricardo, Luan, Eric, Sheydson e Eduardo meus companheiros de moradia e irmãos da vida, a convivência com vocês tornaram as coisas mais fáceis e divertidas.
Vou levar comigo todas as nossas histórias.
Sou grato ao professor João Paulo pela paciência, por todo o conhecimento transmitido,
pelos momentos de descontração e por ter me aceitado como seu orientando e juntamente
aos professores João Borges, Luiz Paulo e Gilson, os quais sou grato por todo os ensinamentos e formação profissional, por terem me aceito como membro do LabEPI, o lugar que
indicaria para qualquer aluno como um agradável ambiente de estudo. Agradeço também
ao professor Gilson pelas caronas e por me dar a oportunidade de iniciar meu caminho de
tutoria no Instituto Metrópole Digital.
Aos professores Deilson, Adrianne, Fabrı́cio, Taciano, Flavius, Karliane e Aislânia pelos
ensinamentos, instruções durante todo o meu tempo nesta universidade e contribuições
para minha formação.
Aos meus amigos de laboratório, Francimar, Daniel, Anderson, Jackson e Eduardo pela
convivência diária, pelas madrugadas de estudo e pelo conhecimento compartilhado, considero vocês como meus irmãos.
Ao meu vizinho Seu Wagner, uma pessoa de bom coração que me acolheu durante toda
a minha estadia em Caicó, a Karliane e Ana Cláudia pelo companheirismo no Instituto
Metrópole Digital, a Petrus por solucionar as questões burocráticas e a todos os meus
colegas de curso, seria impossı́vel citar todos vocês aqui, mas deixo o meu muito obrigado
pela oportunidade de conviver com cada um de vocês.
Finalmente, sou grato pela oportunidade de desenvolver este trabalho no Laboratório
de Elementos do Processamento da Informação (LabEPI), sediado no Centro de Ensino
Superior do Seridó da Universidade Federal do Rio Grande do Norte.
Resumo
Diante da versatilidade, do crescimento tecnológico, da popularização e convergência
digital em torno dos dispositivos móveis, aliado ao avanço da infraestrutura nas redes de
computadores, surgiu a ideia do desenvolvimento de um aplicativo com o intuito de obter
informações relacionadas à descoberta de infraestrutura e serviços de rede. O objetivo
deste trabalho consiste na construção de um aplicativo que irá permitir ao usuário obter
informações para que seja possı́vel analisar determinados aspectos numa determinada rede
no que diz respeito à sua infraestrutura e/ou disponibilidade de serviços. O sistema a ser
desenvolvido consiste em duas funcionalidades principais: um módulo de descoberta de
serviços, para coletar informações obtidas por meio de um dispositivo com a finalidade
de identificar e classificar o status das portas de uma máquina alvo; e uma ferramenta de
descoberta de rotas, para o rastreio do caminho percorrido por um pacote em uma rede de
computadores, possibilitando a visualização de informações referentes à infraestrutura da
rede desde o dispositivo de origem até o destino, além do tempo gasto para obter a resposta
para cada roteador encontrado. O aplicativo permitirá ainda o envio das informações
obtidas pelos dispositivos para uma base de dados disponı́vel em um servidor remoto,
através de um Web Service, proporcionando a centralização dos dados. Conclui-se que
os resultados obtidos com o aplicativo desenvolvido são considerados satisfatórios, visto
que é possı́vel realizar a captura e obter resultados coerentes em ambas as aplicações e
armazená-las da maneira programada.
Palavras-chave: Dispositivos Móveis; Descoberta de serviços e infraestrutura; Redes
de Computadores.
Abstract
Facing the versatility, the technological growth, the popularization and digital convergence around mobile devices, combined with the advancement of infrastructure of computer networks, came the idea of developing an application in order to obtain information
regarding the discovery of infrastructure and network services. This work consists of building an application that will allow the user to obtain information so it is possible to analyze
certain aspects of a given network regarding its infrastructure and / or service availability.
The system to be designed consists of two main features: a service discovery module to
collect information obtained from a device in order to identify and classify the status of
the doors of a target machine; and a route discovery tool, for screening the path taken by a
packet in a computer network, enabling the visualization of information about the network
infrastructure from the source device to the destination, in addition to the time spent to
get the answer for each router found. The application will also allow the transmission of
information obtained by the devices to a database available on a remote server via Web
Service, providing centralization of data. It is concluded that the results obtained with
the developed application are considered satisfactory, since it is possible to capture and
obtain consistent results in both the applications and store them in the programmed way.
Keywords: Mobile Devices; Discovery services and infrastructure; Computer Network;
Descoberta de Infraestrutura e Serviços de Rede
i
Sumário
Lista de Figuras
iii
Lista de Tabelas
v
Lista de siglas e abreviações
vii
Lista de marcas registradas
ix
1 Introdução
1.1 Uma ferramenta Voltada para
1.2 Justificativa . . . . . . . . . .
1.3 Objetivos . . . . . . . . . . .
1.4 Objetivos Especı́ficos . . . . .
1.5 Organização do Documento .
Serviços
. . . . .
. . . . .
. . . . .
. . . . .
de Rede
. . . . .
. . . . .
. . . . .
. . . . .
2 Revisão Bibliográfica
2.1 Fundamentos de Redes de Computadores . . .
2.1.1 Pilha de Protocolos TCP/IP . . . . . .
2.1.2 Protocolos . . . . . . . . . . . . . . . . .
2.1.3 Desenvolvimento de Aplicações em Rede
2.2 Descoberta de Serviços . . . . . . . . . . . . . .
2.3 Descoberta de Rotas . . . . . . . . . . . . . . .
2.4 MongoDB . . . . . . . . . . . . . . . . . . . . .
2.5 Web Services . . . . . . . . . . . . . . . . . . .
3 Desenvolvimento
3.1 Introdução . . . . . . . . . . . . . . . . . . .
3.2 Procedimentos Metodológicos . . . . . . . .
3.2.1 Caracterização da Pesquisa . . . . .
3.2.2 Estudo Bibliográfico . . . . . . . . .
3.2.3 Estudo Técnico . . . . . . . . . . . .
3.2.4 Desenvolvimento do Aplicativo . . .
3.2.5 Validação das Ferramentas e Testes .
3.3 Implementação da Biblioteca PingWrapper
3.4 Implementação da Biblioteca PortScan . . .
3.5 Arquitetura da Aplicação . . . . . . . . . .
3.6 Desenvolvimento da Classe de Conexão com
3.7 Implementação do Web Service . . . . . . .
.
.
.
.
.
.
.
.
.
.
o
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
Banco
. . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
1
2
4
5
5
5
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
7
7
7
9
10
11
12
15
16
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
de Dados
. . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
19
19
20
20
21
21
21
21
22
22
23
24
26
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
ii
Sumário
3.8
3.9
Desenvolvimento do Aplicativo . . . . . . . . . . . . . . . . . . . . . . . . . 26
Validação do Aplicativo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
4 Considerações Finais
41
4.1 Conclusão . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
4.2 Contribuições . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
4.3 Trabalhos Futuros . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
A Apêndice para Desenvolvedor
A.1 Android . . . . . . . . . . . . . . . . . . . . . . .
A.1.1 Arquitetura Android . . . . . . . . . . . .
A.1.2 Componentes de uma Aplicação Android
A.2 Ambiente de Desenvolvimento . . . . . . . . . . .
A.2.1 JDK . . . . . . . . . . . . . . . . . . . . .
A.2.2 Android SDK . . . . . . . . . . . . . . . .
A.2.3 Eclipse IDE . . . . . . . . . . . . . . . . .
A.3 Configuração do Ambiente Android . . . . . . . .
A.3.1 ADT . . . . . . . . . . . . . . . . . . . . .
A.3.2 AVD . . . . . . . . . . . . . . . . . . . . .
A.4 Repositório . . . . . . . . . . . . . . . . . . . . .
A.5 Execução do Aplicativo . . . . . . . . . . . . . .
Referências Bibliográficas
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
45
45
46
47
48
48
49
49
49
49
50
52
53
58
iii
Lista de Figuras
1.1
Porcentagem de uso de sistemas operacionais móveis. . . . . . . . . . . . . .
2.1
2.2
2.3
2.4
2.5
2.6
2.7
2.8
2.9
Pilha de protocolos TCP/IP. . . . . . . . . . . . . . . . . .
Cabeçalho do protocolo IP. . . . . . . . . . . . . . . . . . .
Traceroute em funcionamento em rede local com firewall. .
Traceroute em funcionamento em rede local sem firewall. .
Funcionamento do traceroute. . . . . . . . . . . . . . . . .
Exemplo de criação de documento com MongoDB. . . . . .
Exemplo de criação de documento com MongoDB. . . . . .
Exemplo de persistência de um documento com MongoDB.
Funcionamento do Web Service com SOAP. . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
8
12
13
14
14
15
16
16
16
3.1
3.2
3.3
3.4
3.5
3.6
3.7
Arquitetura da aplicação. . . . . . . .
Tela inicial do aplicativo. . . . . . . .
Tela do PingWrapper. . . . . . . . . .
Tela do PortScan. . . . . . . . . . . . .
Exemplo de captura do PingWrapper.
Exemplo de captura do PortScan. . . .
Tela com mensagens de alerta. . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
24
27
28
29
30
31
32
4.1
Exemplo de composição de rotas com o Zenmap. . . . . . . . . . . . . . . . . 43
A.1
A.2
A.3
A.4
A.5
A.6
A.7
A.8
Arquitetura em camadas no Android. . . . . . . . . . . . . . . . . . .
Download do plugin ADT para Eclipse. . . . . . . . . . . . . . . . . .
Download do plugin ADT para Eclipse. . . . . . . . . . . . . . . . . .
Diálogo Install do Eclipse mostrando o plugin Android para download.
Lista de componentes a serem instalados. . . . . . . . . . . . . . . . .
Gerenciador AVD. . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Criação de um novo AVD. . . . . . . . . . . . . . . . . . . . . . . . . .
Configuração para o modo de desenvolvimento no dispositivo. . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
3
46
50
50
51
51
52
53
54
iv
Lista de Figuras
v
Lista de Tabelas
2.1
Tipos de mensagens ICMP. . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
3.1
3.2
3.3
3.4
3.5
3.6
3.7
3.8
3.9
3.10
3.11
3.12
3.13
3.14
3.15
3.16
3.17
3.18
3.19
3.20
Tempo para escrita de n registros em milissegundos. . . . . . . . . . . .
Tempo para leitura de n registros em milissegundos. . . . . . . . . . . .
Tempo para buscar todos os n registros em milissegundos. . . . . . . . .
Lista de endereços IP analisados. . . . . . . . . . . . . . . . . . . . . . .
Comparação de captura para o endereço 67.23.234.115 . . . . . . . . . .
Comparação de captura para o endereço 48.171.116.178 . . . . . . . . .
Comparação de captura para o endereço 241.58.10.22 . . . . . . . . . . .
Comparação de captura para o endereço 67.23.234.115 . . . . . . . . . .
Lista de portas analisadas. . . . . . . . . . . . . . . . . . . . . . . . . . .
Comparação entre ferramentas portscan para o endereço 67.23.234.115. .
Comparação entre ferramentas portscan para o endereço 48.171.116.178.
Comparação entre ferramentas portscan para o endereço 200.147.67.142.
Comparação entre ferramentas portscan para o endereço 241.58.10.22. .
Comparação entre ferramentas portscan para o endereço 104.28.6.64. . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
25
25
25
32
33
33
34
34
35
35
36
36
36
37
37
38
38
39
39
40
vi
Lista de Tabelas
vii
Acrônimos
ACK . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Acknowledgement
ADT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Android Development Tools
API . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Application Programming Interface
ARP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Address Resolution Protocol
AVD . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Android Virtual Device
BGP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Border Gateway Protocol
DHCP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Dynamic Host Configuration Protocol
GPS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Global Positioning System
GSM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Global System for Mobile Communications
GSMA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Groupe Speciale Mobile Association
ICMP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Internet Control Message Protocol
IDE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Integrated Development Environment
IP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Internet Protocol
IPv4 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Internet Protocol version 4
IPv6 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Internet Protocol version 6
JDK . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Java Development Kit
OSPF . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Open Shortest Path First
RIP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .Routing Information Protocol
RST . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Reset
RTT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .Round Trip Time
SDK . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Software Development Kit
SQL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Structured Query Language
SYN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Synchronize
TCP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Transmission Control Protocol
TTL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Time To Live
UDP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . User Datagram Protocol
URL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Uniform Resource Locator
XML . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . eXtensible Markup Language
viii
ix
R
Android
R
Eclipse
R
Facebook
R
Google
R
IBM
R
Intel
R
Java
R
LG
R
Microsoft
R
MongoDB
R
Motorola
R
Nextel
R
Nvidia
R
Open Handset Alliance
R
Samsung
R
Windows Mobile
R
Youtube
As várias marcas listadas nessa página têm o objetivo de informar aos
leitores que o autor deste trabalho utiliza tais nomes apenas para fins editoriais,
buscando com isso beneficiar o dono da Marca Registrada, sem haver infracão
nas regras de sua utilização.
x
1
Capı́tulo 1
Introdução
“Sometimes it’s the very people who no-one imagines
anything of who do the things that no-one can imagine.”
Alan Turing
Com a evolução da tecnologia, os dispositivos móveis se tornaram ferramentas poderosas
no que se refere à sua capacidade de armazenamento e processamento. A melhoria do
hardware permitiu que aplicações mais robustas fossem desenvolvidas e, com isso, softwares que precisavam ser executados em computadores pessoais passaram à operar com
maior mobilidade. Com um smartphone em mãos, o usuário tem a possibilidade de usar
funcionalidades tais como GPS (Global Positioning System), navegadores, sensores de
movimento e câmeras, antes disponı́veis apenas em dispositivos com finalidade especı́fica.
Devido à unificação de elementos tecnológicos e à baixa nos preços de dispositivos verificase um considerável crescimento no número de aparelhos utilizados mundialmente. Segundo
a GSMA (Groupe Speciale Mobile Association), associação de fabricantes de dispositivos
GSM (Global System for Mobile Communications), um estudo feito no ano de 2014 constatou que o número de dispositivos móveis conectados à Internet ao redor do mundo
chegou a 6 bilhões em novembro de 2011. Nesse mesmo perı́odo, o número de seres humanos chegava a 7 bilhões (Association, 2014). A partir desse crescimento no mundo dos
dispositivos móveis, surgiu uma plataforma capaz de permitir aos desenvolvedores a total
utilização dos inúmeros recursos disponibilizados atualmente: a plataforma de desenvolvimento Android (Deitel et al., 2012).
A definição da plataforma Android para a construção de aplicativos, comumente
chamados de apps, se deve, principalmente, a fatores inerentes ao próprio desenvolvimento
das aplicações. Por ser baseado no Linux e possuir licença aberta, vários desenvolvedores
podem contribuir para que o sistema tire um melhor proveito de novas tecnologias e recursos implementados no kernel do Linux. Outro fator que facilita o desenvolvimento
no Android é a permissão para manipular os recursos de hardware disponı́veis, provendo
ao desenvolvedor o controle sobre componentes que podem ser úteis para determinados
aplicativos. O grande número de dispositivos móveis que suportam o sistema operacional
também colabora para a implementação nesta plataforma, visto que é possı́vel executar
um mesmo programa utilizando aparelhos de diferentes fabricantes com hardware distintos
(Mednieks et al., 2012).
Essa explosão no número de dispositivos móveis foi impulsionada pela possibilidade de
comunicação entre eles. Através do uso das Redes de Computadores, a Internet tornou-se o
2
Capı́tulo 1. Introdução
principal canal de conversação entre os dispositivos por meio das aplicações desenvolvidas,
tornando possı́vel o desenvolvimento de aplicativos que usam a Internet para se comunicarem, bem como de sistemas que são criados para obter informações da própria rede e de
seus componentes, caso contrário, os dispositivos móveis e suas aplicações estariam fadados a se igualar a sistemas para desktop, onde a disponibilidade de suas funcionalidades
são fornecidas de forma local (Araújo, 2010).
Para Kurose e Ross (2013) a Internet é provavelmente o maior sistema de engenharia
já criado pela humanidade, com centenas de milhões de computadores conectados, enlaces
de comunicação e comutadores; bilhões de usuários que se conectam por meio de laptops,
tablets e smartphones.
Em novembro de 2007, a Google e outras 33 empresas que formam a Open Handset
Alliance (Aliança de Telefonia Móvel Aberta) divulgaram um comunicado à imprensa com
o seguinte conteúdo:
“Esta Aliança partilha uma meta comum de inovação em dispositivos
móveis e de fornecimento aos consumidores de uma experiência de
usuário muito superior a de muitos produtos disponı́veis em plataformas móveis da atualidade. Fornecendo aos desenvolvedores um novo
nı́vel de abertura que permite um trabalho mais colaborativo, o Android acelerará o ritmo em que novos serviços móveis e competitivos
serão disponibilizados aos consumidores” (Rogers et al., 2009).
O Android trouxe aos desenvolvedores a liberdade para criar, de maneira autônoma,
aplicações com diversas finalidades e disponibilizá-las de forma gratuita ou paga, de acordo
com cada interesse. Além disso, o Android se tornou atrativo devido ao grande número
de aparelhos rodando seu sistema operacional, pois mesmo que o aplicativo não seja pago,
poderá trazer grande visibilidade dependendo do tipo de serviço que está sendo ofertado
Segundo a Index (2014) dois terços dos usuários de dispositivos móveis utilizam o sistema
operacional Android. Junto a isso, o Android tem o apoio de empresas com um grande
número de consumidores como LG, Motorola, Samsung, Nextel, Intel e NVidia, todas
contribuindo para a Open Handset Alliance (Ogliari e Brito, 2014). Na Figura 1.1 é
apresentado o percentual de usuários de diversos sistemas operacionais para dispositivos
móveis entre os anos de 2011 à 2014.
O Android tem potencial para remover as barreiras para o sucesso no desenvolvimento
e venda de uma nova geração de software de telefonia móvel Rogers et al. (2009).
Perante as circunstancias atuais, a união entre dispositivos móveis e redes de computadores torna-se inevitável. Ferramentas que alinhem essas duas tecnologias tornam-se
úteis na concepção de novos aplicativos que necessitem, de alguma forma, interagir com a
Internet ou obter dados sobre seus serviços e infraestrutura.
1.1
Uma ferramenta Voltada para Serviços de Rede
Uma empresa precisa conhecer bem seus funcionários, saber se eles desempenham
corretamente uma função, qual departamento é mais eficiente ou até mesmo se eles interagem bem com outras partes da organização. Todas essas informações são necessárias
para garantir a qualidade na execução dos projetos. Nas redes de computadores de uma
empresa, ou até mesmo na Internet, também é assim. É preciso conhecer os equipamentos,
como eles se conectam, seu desempenho, entre outras métricas para assegurar o correto
1.1. Uma ferramenta Voltada para Serviços de Rede
3
Figura 1.1: Porcentagem de uso de sistemas operacionais móveis.
Fonte: (Index, 2014).
funcionamento. Em uma determinada rede podem haver dezenas ou até milhares de dispositivos, portanto, caso algo dê errado a inexistência de documentos que descrevam como
a rede está estruturada em relação à sua organização, segurança e interligação tornará
mais complexa a descoberta da origem da falha. Como solução para estes problemas, existem ferramentas que permitem coletar diversas informações de equipamentos e serviços
da rede.
Para obter determinadas medidas, as ferramentas podem realizar um monitoramento
passivo, na qual ela analisa dados existentes ou um monitoramento ativo, quando a ferramenta poderá interferir no sistema, gerando tráfego de dados para conseguir as informações
necessárias e avaliar o funcionamento de um sistema Tanenbaum (2003). Além de coletar
os dados, é interessante que as ferramentas armazene-os para que seja possı́vel uma análise
subsequente. Para que o gerenciamento de uma rede de computadores seja feito de forma
correta, alguns utilitários são fundamentais para que o responsável possa administrá-la,
tornando funcional toda a infraestrutura e disponibilizando os serviços necessários (Peres
et al., 2014).
A partir deste contexto, pode-se perceber a importância da utilização, nas redes
de computadores, de ferramentas capazes de executar tarefas essenciais para se obter
parâmetros que possibilitem uma avaliação sobre a disponibilidade de serviços e/ou infraestrutura de uma rede. A integração de diversos utilitários para monitoramento em
redes de computadores faz-se um instrumento capaz de trazer ao usuário maior praticidade. Além disso, com o avanço tecnológico sobre os dispositivos móveis no que se refere
à capacidade de processamento e comunicação, aplicações de rede podem ser desenvolvidas trazendo outras vantagens. A mobilidade se torna um dos fatores para a criação de
aplicativos voltados para a obtenção de informações a partir de redes de computadores,
pois não será preciso carregar grandes equipamentos para coletar os dados necessários, já
que terá disponı́vel um sistema que fornecerá informações de forma imediata, propiciando
4
o envio e recebimento de informações remotamente.
1.2
Justificativa
As redes de computadores proporcionam que indivı́duos possam trabalhar em conjunto, compartilhando informações, otimizando o desempenho na realização de tarefas e
estão presentes no dia-a-dia da sociedade. Elas são estruturas sofisticadas e complexas,
mantendo os dados e informações ao alcance de seus usuários. Um fator importante no
que diz respeito à comunicação através redes de computadores é a definição da maneira
como os diferentes dispositivos estão interligados. Estas formas de conexão são conhecidas
como topologia. Medeiros (2014) descreve que topologia de rede é qualquer descrição da
interconexão de seus nós em um determinado instante de tempo. Estes nós podem estar
interconectados de várias formas, tanto do ponto de vista fı́sico quanto lógico.
De acordo com Medeiros et al. (2015) a partir do conhecimento sobre a topologia de
uma rede é possı́vel obter informações relevantes sobre a sua infraestrutura relacionadas
ao número de dispositivos conectados e a forma na qual essas ligações ocorrem. Medeiros
et al. (2015) realizou um estudo sobre mecanismos de monitoramento em redes de computadores baseando-se na topologia para distribuir sensores a fim de coletar informações
sobre o estado da rede, descrevendo que a distribuição destes sensores pode ser realizada
nas bordas da rede, permitindo que a captura das informações seja feita de forma descentralizada, facilitando a utilização de dispositivos móveis para esta finalidade. Além das
informações proporcionadas pela infraestrutura de uma rede, os serviços disponibilizados
por ela também são relevantes para o conhecimento de toda a estrutura.
Aliado às exigências já conhecidas sobre o entendimento em topologias de rede, a
origem de um novo conceito denominado de IoT (Internet of Things) que visa proporcionar
à comunicação direta entre qualquer objeto que possa estar conectado a Internet, traz a
necessidade de conhecimento sobre novos conceitos nas redes de computadores. Segundo
Lopez et al. (2013), a nova geração de usuários da Internet quer ir além da conexão de
pessoas em redes sociais, querem controlar todas as “coisas” em suas vidas a qualquer hora
e qualquer lugar, auxiliados pela tecnologia dos smartphones. A IoT está sendo aplicada
em uma série de áreas como, por exemplo, controle de iluminação, gestão de tráfego e
controle ambiental, formando uma espécie de cidade inteligente (Wei e Jin, 2012).
A criação da chamada Internet das Coisas, tornando simples objetos em dispositivos
interligados, possibilita à obtenção de informações referentes a disponibilidade de serviços
em cada “coisa” conectada à Internet. Dispositivos ligados a Internet podem fornecer
algum tipo de serviço e, no sentido de identificar quais serviços poderiam ou não estar
disponı́veis em um determinado dispositivo, a utilização de uma ferramenta com este
propósito torna-se útil. Baseado no status das portas de rede de alguma “coisa” conectada
a Internet pode-se descobrir qual a configuração de um determinando dispositivo no que
diz respeito a disponibilidade de serviços, pois os dispositivos podem está presentes em
ambientes totalmente dinâmicos, onde constantemente correm o risco de ser danificados ou
até mesmo desaparecer devido às perdas de conexão, mobilidade ou limitação de recursos
(Wei e Jin, 2012).
Diante destes cenários, justifica-se o desenvolvimento de uma ferramenta capaz de
obter as rotas de uma determinada rede, descobrindo o caminho percorrido pelos dados
do dispositivo de origem até o destino, bem como o tempo gasto para se chegar a cada
um dos dispositivos, colaborando para a descoberta da topologia de uma rede, assim como
1.3. Objetivos
5
de uma aplicação que permita coletar informações sobre a disponibilidade de serviços em
um determinado dispositivo, através da verificação do status das suas portas de rede. O
armazenamento das informações referentes ao traçado de rotas torna-se útil, pois os dados
coletados podem ser válidos para determinar a topologia de alguma rede, assim como as
informações sobre a disponibilidade de serviços com a finalidade de recolher referências que
podem ser importantes em questões de segurança. Sendo assim, um módulo que permita
a persistência dos dados coletados pelas ferramentas também será implementado.
1.3
Objetivos
Tem-se por objetivo geral o desenvolvimento de uma aplicação para dispositivos móveis,
utilizando a plataforma de desenvolvimento Android, que tem como finalidade obter e armazenar informações coletadas em diversos momentos, referentes a descoberta de serviços
e traçado de rotas nas redes de computadores.
1.4
Objetivos Especı́ficos
Nos tópicos a seguir serão descritos os objetivos especı́ficos deste trabalho:
1. Implementação de uma biblioteca para o traçado de rotas e descoberta de infraestrutura de rede;
2. Implementação da aplicação portscan para a descoberta de serviços de rede;
3. Construção de um ambiente para armazenar os dados coletados; e
4. Desenvolver um aplicativo para dispositivos móveis que executem o sistema operacional Android incorporando as funcionalidades anteriormente desenvolvidas.
1.5
Organização do Documento
Este trabalho contém, além deste capı́tulo, outros tópicos que englobam aspectos referentes aos conceitos necessários para o desenvolvimento deste trabalho. O documento
está organizado em cinco capı́tulos e um apêndice. O Capı́tulo 2 que diz respeito ao referencial teórico o qual é a base de estudo deste projeto e demonstra a importância do uso de
ferramentas de rede para um bom funcionamento e comunicação de toda a infraestrutura
e disponibilidade de serviços. Ao final do capı́tulo, uma fundamentação teórica sobre as
ferramentas portscan e traceroute é realizada com a intenção de esclarecer o funcionamento de cada uma e suas principais caracterı́sticas, assim como exibe as propriedades do
MongoDB, base de dados que será utilizada para armazenar as informações coletadas.
No Capı́tulo 3, são demonstrados os procedimentos metodológicos empregados para
alcançar os objetivos deste trabalho, além de relatar como foi realizada a implementação
dos objetivos deste trabalho, bem como os testes e os resultados obtidos. No Capı́tulo 4,
é apresentada uma avaliação sobre as atividades desempenhadas neste projeto. Por fim,
no Apêndice A, são descritas informações sobre o ambiente de desenvolvimento e ilustra
a configuração dos componentes necessários para organização da estrutura na plataforma
Android, além de conter referências para a visualização dos código-fontes desenvolvidos
neste trabalho.
6
7
Capı́tulo 2
Revisão Bibliográfica
“If knowledge can create problems, it is
not through ignorance that we can solve them.”
Isaac Asimov
Este Capı́tulo está organizado da seguinte forma: Na Seção 2.1, são descritos fundamentos básicos sobre redes de computadores com a finalidade de elucidar alguns conceitos
desta área, assim como mecanismos utilizados em aplicações que façam uso das redes
de computadores. Ainda neste capı́tulo, o funcionamento das ferramentas portscan e
traceroute, que também são objetos de estudo deste trabalho, serão explicadas, respectivamente, nas Seções 2.2 e 2.3. Já na Seção 2.4, as propriedades, particularidades e
principais caracterı́sticas do MongoDB, banco de dados orientado a documentos, que será
aplicado no desenvolvimento deste estudo, serão relatadas. Por fim, na Seção 2.5 alguns
conceitos sobre Web Services serão apresentados.
2.1
Fundamentos de Redes de Computadores
Redes de computadores se tornaram imprescindı́veis devido à sua eficiência em interconectar centenas de milhões de dispositivos de computação em todo o mundo (Tanenbaum, 2003). A capacidade de alcançar grandes áreas geográficas faz com que quilômetros
de distância se aproximem devido à Internet. Para que toda essa complexa estrutura
funcione e os dispositivos a ela conectados possam se comunicar, protocolos precisaram
ser criados para padronizar a comunicação entre eles. Em uma era em que a maioria
dos dispositivos móveis contém hardware diferentes, especificações diferentes e fabricantes
diferentes, as comunicações entre eles são feitas graças às convenções criadas no desenvolvimento dos protocolos. Segundo Kurose e Ross (2013), aplicações de rede são a razão
de ser de uma rede de computadores. Se não fosse possı́vel inventar aplicações úteis, não
haveria necessidade de projetar protocolos de rede para suportá-las.
De modo que esse trabalho tem como finalidade principal a obtenção de dados a partir
de redes de computadores, uma descrição sobre a pilha de protocolos TCP/IP será feita
com o intuito de elucidar conceitos que serão empregados neste estudo.
2.1.1
Pilha de Protocolos TCP/IP
O TCP/IP é o principal protocolo de envio e recebimento de dados na Internet. Sua
nomenclatura é formada pela junção de dois importantes protocolos (que serão detalha-
8
Capı́tulo 2. Revisão Bibliográfica
dos em seções posteriores), o TCP (Transmission Control Protocol ) (Postel, 1981b) e IP
(Internet Protocol ) (Postel, 1998). O conjunto de protocolos contidos neste modelo é dividido em camadas que se comunicam, onde cada uma é responsável por executar tarefas
para que a comunicação entre dois dispositivos ocorra. A pilha de protocolos TCP/IP é
ilustrada na Figura 2.1.
Computador A
envia os dados.
Computador B
recebe os dados.
Pilha de
protocolos TCP/IP
Aplicação
Aplicação
Transporte
Transporte
Rede
Rede
Rede
Enlace
Enlace
Física
Física
Figura 2.1: Pilha de protocolos TCP/IP.
Fonte: Adaptada de Kurose e Ross (2013).
O TCP/IP trabalha em etapas, percorrendo cada camada e transmitindo as informações
para a camada seguinte. Uma breve descrição, partindo do mais alto nı́vel sobre o comportamento de cada camada será feita a seguir.
Na camada de Aplicação, os protocolos são especı́ficos para a finalidade de cada programa que faz uso da rede. Sendo assim, por exemplo, existe um protocolo para a comunicação entre um cliente Web (Fielding et al., 1999) e um servidor Web, um protocolo
para a comunicação entre um cliente Telnet (Postel e Reynolds, 1983) e um servidor Telnet
e assim por diante. Os protocolos da camada de transporte fornecem uma comunicação
lógica entre as aplicações que estão sendo executadas (Kurose e Ross, 2013). Os protocolos da camada de transporte podem solucionar problemas de confiabilidade, verificando
se os dados chegaram a seu destino, assim como de integridade, certificando que os dados
chegaram em sua totalidade. Os protocolos da camada de transporte, concedem a cada
programa um número de porta, que é acrescentado a cada pacote para determinar a qual
aplicação ele será destinado e os pacotes, chamados de segmentos, são enviados para a
camada de rede.
Na camada de transporte, utilizamos portas para identificar os processos que estão
2.1. Fundamentos de Redes de Computadores
9
se comunicando entre os diferentes computadores. Agora, na camada de Rede, usamos o
endereço IP para identificar os hosts que fazem parte de uma conexão (Peres et al., 2014).
Ao receber os segmentos da camada anterior, a camada de rede encapsula os segmentos
em datagramas IP e, por meio de algum protocolo de roteamento, encaminha-o para o
computador de destino, com base no endereço IP.
Além do endereçamento entre origem e destino, a camada de rede possui protocolos que
permitem a descoberta de computadores vizinhos em uma mesma rede, bem como para
a descoberta de computadores em outras redes. Os Protocolos ICMP (Internet Control
Message Protocol) (Postel, 1981a), ARP Address Resolution Protocol (J. Arkko, 2009),
IP e protocolos de roteamento como: RIP (Routing Information Protocol ) (Postel, 1998),
OSPF (Open Shortest Path First) (Moy, 1998) e BGP (Border Gateway Protocol ) (Rekhter
et al., 2006) são alguns dos responsáveis por realizarem as tarefas atribuı́das à camada de
rede.
Ao receber os datagramas da camada de rede, a camada de enlace, camada lógica de
mais baixo nı́vel na pilha de protocolos, eles têm a responsabilidade de transferir datagramas de um host para outro por meio de um enlace. Enlaces são canais de comunicação que
conectam hosts adjacentes através de um caminho. Essa camada determina os detalhes
de como a informação é enviada fisicamente pela ultima cada da pilha de protocolos, seja
por um cabo de par trançado, fibra ótica ou sem fio.
2.1.2
Protocolos
A implementação das ferramentas envolvidas neste trabalho dependem de um razoável
entendimento sobre os protocolos que serão aplicados. Diante disso, será abordada a
importância e principais conceitos de cada protocolo.
O TCP é um protocolo da camada de transporte e tem como objetivo o envio/recebimento de dados de forma confiável ao seu destino. A confiabilidade do TCP é baseada
no controle de conexão criada pelo protocolo. Antes de iniciar a transmissão de dados de
uma aplicação, o TCP requisita ao servidor o estabelecimento de uma conexão a qual o
servidor pode ou não aceitar. Para obter a conexão, o protocolo realiza um procedimento
denominado three-way-handshake com o intuito de realizar uma sincronização entre as entidades envolvidas na transmissão para que informações sejam transferidas corretamente
(Peres et al., 2014).
Outro ponto importante do protocolo TCP é o controle de fluxo. O receptor, enquanto recebe os dados, envia mensagens confirmando a recepção dos dados para o emissor, servindo de parâmetro para que o receptor não seja sobrecarregado com o envio de
mensagens, já que as velocidades de transmissão de ambos podem ser diferentes causando
perda dos dados transmitidos Kurose e Ross (2013).
Além do TCP, outro protocolo da camada de transporte bastante utilizado em aplicações
é o UDP (User Datagram Protocol ) (Postel, 1981c). O UDP é um protocolo simples e não
orientado à conexão, não fornecendo garantia de que os dados chegarão a seu destino.
Por não ser orientado a conexão esse protocolo é usado em aplicações onde é necessária a
entrega dos dados de maneira mais rápida e não é preciso ocorrer retransmissão em caso
de falhas. Sendo assim, ao contrário do TCP, o UDP não possui controle de fluxo, apenas
uma verificação de integridade. Ele realiza a tentativa de entrega dos dados e caso algum
dado sofra alteração no caminho até o destinatário, o pacote será descartado (Peres et al.,
2014).
10
O protocolo IPv4 (Internet Protocol version 4 ), que pertence à camada de rede,
é utilizado para endereçar hosts para os quais os pacotes serão transmitidos. O endereço IP é um número de 32 bits, que representado em decimal tem a seguinte forma:
“189.124.133.180”. Cada parte do endereço é responsável pela identificação de um componente, seja uma rede ou um dispositivo especı́fico. A parte inicial do endereço faz
referência a uma rede existente e a segunda identifica um host (Peres et al., 2014). Cada
equipamento que esteja em rede deve possuir um endereço IP único, para que seja possı́vel
a entrega correta dos dados pelos roteadores.
No inı́cio do desenvolvimento do protocolo IPv4, acreditou-se que a quantidade de endereços fornecidos por ele fosse suficiente para suprir os equipamentos existentes, mas com
o avanço tecnológico e o surgimento de diversos dispositivos análogos aos computadores,
como smartphones, relógios e até electrodomésticos, em 1990, iniciou-se o desenvolvimento
de um protocolo sucessor do IPv4, o IPv6 (Internet Protocol version 6 ) (Deering e Hinden,
1998) (Peres et al., 2014). Como principal evolução, o IPv6 amplia o número de endereços
disponı́veis a uma escala muito maior.
Enquanto o IPv4 fornece 4 bilhões de endereços com seus 32 bits, seu sucessor fornece,
para endereçamento, 128 bits. Além da expansão de sua capacidade, o IPv6 implementa
em sua estrutura o uso obrigatório do IPsec (IP Security) (Frankel e Krishnan, 2001),
antes opcional no IPv4. O IPsec é um protocolo que fornece serviços de segurança como:
confiabilidade, integridade e autenticidade na camada de rede, concedendo uma garantia
adicional, já que a própria camada não provê recursos de segurança (Brito, 2013).
Junto ao IP, na camada de rede, está o ICMP, o qual é utilizado para comunicação de
erros. O ICMP tem como função notificar eventos ocorridos durante a transmissão pelos
roteadores, mas é usado principalmente para alertar sobre possı́veis falhas (Peres et al.,
2014). O utilitário ping, usado para testar conexões entre equipamentos faz uso do ICMP
para obter informações da rede. Assim como o ping, o ICMP é empregado na ferramenta
traceroute, objeto de estudo neste trabalho, que nos permite estimar a rota percorrida
por um pacote até o seu destino. Na Tabela 2.1 é apresentado os tipos de mensagem
ICMP.
2.1.3
Desenvolvimento de Aplicações em Rede
A comunicação entre aplicações se tornou indispensável nos sistemas atuais, permitindo
a troca de informações entre dispositivos. Uma das tecnologias utilizadas para essa interação são os sockets. Sockets são mecanismos de comunicação usados para a troca de
mensagens entre processos que, teoricamente, estão em hosts diferentes (Kurose e Ross,
2013). Para que os hosts possam se comunicar é necessário a utilização de protocolos da
camada de transporte, seja TCP ou UDP (Peres et al., 2014). De acordo com Tanenbaum
(2003) o socket funciona como uma interface entre a camada de aplicação e a de transporte
em uma máquina. Basicamente, os sockets são definidos através de um endereço IP e de
um número de porta do respectivo protocolo de transporte que será usado.
Com essas informações, é possı́vel identificar de maneira única qual o destino da informação a qual aplicação especificamente ela será entregue. Entre os tipos de sockets
existentes, serão abordados o stream socket e o datagram socket. O stream socket fornece
fluxos de comunicação confiáveis, ou seja, caso seja preciso garantir a entrega das informações enviadas ao outro lado da conexão e que a transmissão esteja livre de erros, sua
aplicação será mais apropriada (Kurose e Ross, 2013).
As caracterı́sticas de confiabilidade contidas no stream sockets provém da utilização
2.2. Descoberta de Serviços
11
do protocolo de controle de transmissão, TCP, que garante que os dados cheguem ı́ntegros
e do IP que garante o correto roteamento até o destino. Já o datagram socket também
utiliza o IP para o roteamento, mas não usa TCP, e sim o UDP. Datagram sockets são
conhecidos por serem sockets não orientados à conexão, isso se deve as caracterı́sticas do
UDP, que objetiva a entrega e recebimento dos dados da forma mais rápida possı́vel. Ao
contrário do TCP, o UDP não estabelece uma conexão, a única garantia fornecida pelo
protocolo é a de que caso um pacote sofra alguma alteração entre a origem e o destino ele
o pacote será descartado (Kurose e Ross, 2013).
2.2
Descoberta de Serviços
Nos dias de hoje, quando falamos em segurança nas redes de computadores, citamos
a Internet com bastante frequência, pois é nela que ocorrem a maioria dos ataques em
computadores e, consequentemente, nos serviços ofertados por ela. Um dos maiores problemas referentes a questões de segurança em computadores são as vulnerabilizardes a qual
eles estão expostos, permitindo a exploração de falhas com o intuito de violar sistemas ou
obter informações. Segundo Nakamura e de Geus (2007) possı́veis problemas podem ser
encontrados e potenciais ameaças podem surgir, as quais se destacam:
• Destruição de informações;
• Alteração na integridade das informações;
• Interceptação de informações; e
• Paralisação de serviços.
Diante deste ambiente inseguro, empresas e instituições buscam formas de manter a
segurança de suas informações e a estabilidade em seus serviços através de politicas de
segurança e utilização de ferramentas capazes de monitorar e verificar prováveis problemas.
Um dos métodos que podem ser usados para minimizar tais situações é a aplicação de
ferramentas portscan. Portscan são programas com a capacidade de detectar possı́veis
vulnerabilidades nos serviços ofertados por uma rede de computadores (Lyon, 2012). Eles
objetivam a varredura em portas de rede de um determinado host e, com as informações
obtidas, permitem a busca por falhas de segurança que possam permitir ataques e causar
circunstâncias indesejadas. Em outras palavras, os portscan tem como propósito o teste
em portas de rede em um host especı́fico. Ao realizar esses testes, ele investiga o status
das portas, verificando, basicamente, se estão abertas, fechadas ou filtradas.
Diversas técnicas podem ser utilizadas para examinar o status de uma porta e analisar quais serviços podem estar disponı́veis. Porém, neste trabalho, citaremos três formas
de se realizar essa sondagem, baseando-se nas técnicas de escaneamento suportadas por
uma conhecida ferramenta de varredura de portas, denominado Nmap (Lyon, 2012). Para
facilitar o entendimento sobre cada uma dessas técnicas, na Figura 2.2 é representado o
cabeçalho de um pacote IPv4, contendo os campos que serão utilizados para os procedimentos.
A primeira técnica de varredura de portas é a TCP SYN. Ela tem como principal caracterı́stica a não conclusão de uma conexão TCP com o computador alvo. O host de origem
envia um pacote com o campo flag contendo a flag SYN, para iniciar o estabelecimento
da conexão e aguarda alguma resposta. Caso receba uma flag SYN/ACK, assinala que a
porta está aberta, mas se a resposta obtida for um RST (reset), é provável que a porta
não esteja aberta. Se mesmo após diversas tentativas de conexão não for recebida resposta
12
bytes 0
1
2
3
0
Total Length
Type of Service
IHL
Version
4
Flags
(RDM)
Identification
Fragment Offset
8
Time to Live
Header Checksum
Protocol
12
Source Address
16
Destination Address
20
Options
bits
0
1
2
3
4
5
6
7
8
9
1
0
1
2
3
4
5
6
7
8
9
2
0 1
2
3
4
5
6
7
8
9
3
0 1
R - Reserved
DF - Don't framgment
MF - More fragments
Figura 2.2: Cabeçalho do protocolo IP.
Fonte: Medeiros (2009).
alguma, a porta é classificada como filtrada. A porta também será rotulada como filtrada
caso a origem receba um erro de host inalcançável por um pacote ICMP. A Tabela 2.1
contem os códigos de erro ICMP. É possı́vel perceber que por meio dessa técnica podemos
distinguir com clareza o status obtido para cada porta.
Outra forma de varredura de portas é utilizando a técnica TCP connect. Esse modo de
scanner se torna uma alternativa quando não é possı́vel utilizar o TCP SYN, já que este
ultimo requer privilégios na máquina onde será executado. Ao contrário do TCP SYN, o
TCP connect não envia pacotes em estado bruto ao destinatário, solicitando ao sistema
operacional para que estabeleça uma conexão com o host alvo, enviando chamadas de
sistema connect() (Lyon, 2012). Através das respostas recebidas por cada tentativa de
conexão é possı́vel obter o status de cada porta. Devido ao fato dessa técnica tentar realizar conexões por meio de chamadas de sistemas connect() as conexões são completadas,
fornecendo ao host destino a possibilidade de registro dessas conexões e, caso ele tenha alguma ferramenta que monitore sua rede, essas tentativas de varredura serão identificadas.
O Scan UDP é a ultima técnica a ser descrita nessa seção. Apesar de usar o protocolo
de transporte UDP ao invés do TCP, esse tipo de verificação não é menos importante do
que as citadas anteriormente. Serviços importantes como DNS (Domain Name System)
(Mockapetris, 1987) e DHCP (Dynamic Host Configuration Protocol ) (R. Droms, 1997)
(que tem a finalidade de atribuir dinamicamente endereços IP à dispositivos) trafegam
sobre UDP e podem se tornar potenciais alvos em ataques a um host. De maneira diferente,
o scan UDP encaminha um cabeçalho UDP vazio para a porta escolhida e, caso ocorra um
erro de porta inalcançável com tipo e código 3, indica que a porta está fechada. Outros
erros do tipo 3, mas com os códigos 1, 2, 9, 10 ou 13 determinam a porta como filtrada.
Após outras tentativas de conexão sem resposta a porta é classificada como aberta/filtrada
(Lyon, 2012).
2.3
Descoberta de Rotas
O traceroute é uma ferramenta de diagnóstico em redes de computadores que tem
como objetivo descobrir o caminho percorrido por um pacote de dados, desde o host
de origem até o destino. O traceroute é normalmente utilizado para realizar testes
2.3. Descoberta de Rotas
Tipo
0
3
3
3
3
3
3
4
8
9
10
11
12
Código
0
0
1
2
3
6
7
0
0
0
0
0
0
13
Descrição
Resposta de ECHO.
Rede de destino inalcançável.
Host de destino inalcançável
Protocolo de destino inalcançável.
Porta de destino inalcançável.
Rede de destino desconhecida.
Host de destino desconhecido.
Redução da fonte (controle de congestionamento).
Solicitação de ECHO.
Anuncio do roteador.
Descoberta do roteador.
TTL expirado.
Cabeçalho IP inválido.
Tabela 2.1: Tipos de mensagens ICMP.
Fonte: Adaptada de Kurose e Ross (2013).
na infraestrutura de uma rede, identificando falhas em determinados locais durante o
caminho de transmissão dos dados. Com a resposta obtida da ferramenta, pode-se analisar
e verificar se situações problemáticas como, por exemplo, perceber se algum roteador
está descartando pacotes ou que em alguma parte da rota a transmissão dos dados está
demorando.
O seu mecanismo está baseado na utilização de um valor numérico, representado pelo
campo TTL (Time To Live), presente no cabeçalho IP (Figura 2.2), que controla o tempo
de vida de um pacote em uma rede, como forma de evitar que ele fique no meio de
transmissão por tempo indeterminado. Esse valor é decrementado em 1 cada vez que um
pacote passa por um roteador e, ao alcançar o valor zero, o pacote é descartado e uma
mensagem de erro “TIME EXCEEDED” é emitida pelo protocolo de controle ICMP e
enviada ao host de origem. Nas Figuras 2.3 e 2.4 são apresentadas as informações obtidas
pela ferramenta traceroute tendo como alvo o endereço “scanner.nmap.org”. Na Figura
2.3 é mostrado uma captura em uma rede com regras de firewall para pacotes ICMP,
obtendo informações apenas dos roteadores dentro da própria rede. Na Figura 2.4 é exibida
a captura feita em uma rede sem regras de bloqueio para pacotes ICMP, mostrando todo o
caminho percorrido até chegar ao endereço destino. Por fim, na Figura 2.5 é apresentado
o mecanismo da ferramenta traceroute para exemplificar seu funcionamento.
1
2
3
4
5
6
7
$ traceroute to scanner.nmap.org (173.255.243.189), 30 hops max, 60 byte packets
1 192.168.21.1 (192.168.21.1) 2.869 ms 4.130 ms 4.191 ms
2 flag.labepi.ufrn.br (192.168.0.254) 13.428 ms 13.436 ms 13.798 ms
3 10.142.16.1 (10.142.16.1) 15.363 ms 15.370 ms 15.369 ms
4 * * *
...
30 * * *
Figura 2.3: Traceroute em funcionamento em rede local com firewall.
Fonte: Elaborada pelo autor.
14
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
$ traceroute to scanner.nmap.org (173.255.243.189), 30 hops max, 60 byte packets
1 192.168.0.10 (192.168.0.10) 5.563 ms 5.547 ms 5.540 ms
2 180-105-177-1.sidys.com.br (177.105.180.1) 19.136 ms 19.310 ms 19.438 ms
3 10.30.0.1 (10.30.0.1) 17.014 ms 21.822 ms 21.692 ms
4 sidys.static.gvt.net.br (179.185.39.81) 22.362 ms 22.599 ms 22.686 ms
5 Vlan2098.static.gvt.net.br (179.185.39.60) 74.909 ms 74.792 ms 75.036 ms
6 gvt-te-0-0-0-0.rc02.fla.gvt.net.br (179.185.129.226) 81.367 ms 68.693 ms
68.680 ms
7 177.205.8.103.static.adsl.gvt.net.br (177.205.8.103) 80.560 ms 90.795 ms
90.779 ms
8 gvt-te-0-3-0-4.rc02.sdr.gvt.net.br (187.115.218.226) 94.785 ms 94.792 ms
94.788 ms
9 177.205.10.136.static.adsl.gvt.net.br (177.205.10.136) 93.835 ms 93.445 ms
93.836 ms
10 xe0-1-0-0-grtssatw1.net.telefonicaglobalsolutions.com (84.16.7.157) 68.074 ms
68.050 ms 68.057 ms
11 xe5-2-0-0-grtfortw1.net.telefonicaglobalsolutions.com (84.16.14.242) 104.642 ms
xe7-3-0-0-grtfortw1.net.telefonicaglobalsolutions.com (5.53.5.54) 81.483
ms xe5-2-0-0-grtfortw1.red.telefonica-wholesale.net (84.16.14.242) 44.144 ms
12 xe9-0-6-0-grtmiabr4.red.telefonica-wholesale.net (94.142.123.178) 119.157 ms
119.532 ms te0-3-0-13-grtmiabr6.red.telefonica-wholesale.net (94.142.123.174)
205.060 ms13 xe4-0-1-0-grtdaleq4.net.telefonicaglobalsolutions.com (94.142.119.33)
205.044 ms xe-0-0-2-0-grtdaleq4.red.telefonica-wholesale.net (176.52.251.49)
205.049 ms xe4-0-1-0-grtdaleq4.red.telefonica-wholesale.net (94.142.119.33)
205.032 ms
14 213.140.53.254 (213.140.53.254) 205.028 ms 205.025 ms 205.023 ms
15 10ge9-1.core3.fmt2.he.net (72.52.92.153) 205.036 ms 205.011 ms 205.208 ms
16 router3-fmt.linode.com (65.49.10.218) 205.019 ms router4-fmt.linode.com
(64.71.132.138) 205.202 ms router3-fmt.linode.com (65.49.10.218) 205.193 ms
17 * * *
...
30 * * *
Figura 2.4: Traceroute em funcionamento em rede local sem firewall.
Figura 2.5: Funcionamento do traceroute.
2.4. MongoDB
2.4
15
MongoDB
O MongoDB surgiu como uma nova ideia para o armazenamento de dados em aplicações
que necessitam de flexibilidade na estrutura de seus dados. A definição básica do MongoDB é a utilização do conceito de banco de dados orientados à documentos, que tem
como princı́pio a concepção de que cada documento deve ser autocontido e autodescritivo
ou seja, que cada registro decide como ele deve ser exibido e qual o significado dos dados
salvos na estrutura (Banker, 2011).
Segundo Lennon (2011), por ser orientado a documentos, ele se difere dos tradicionais
bancos de dados relacionais que utilizam esquemas bidimensionais para representar informações por meio de linhas e colunas, se tornando um modelo não relacional. Esse tipo
de base de dados permite ainda o agrupamento de todas as informações significativas em
um único documento, facilitando assim a criação de consultas para obter determinadas
informações, além de permitir a apresentação de todos os dados sem o uso de relacionamentos (propriedade imprescindı́vel nos banco de dados relacionais), gerando assim uma
maior performance. Uma importante propriedade que possibilita ao MongoDB um alto desempenho é a aplicação de redundância e inconsistência em suas informações, propiciando
o retorno de uma consulta sem a necessidade de vasculhar outros documentos.
Outro fundamento do MongoDB consiste na não utilização da linguagem de consulta
SQL (Structured Query Language) para a realização de buscas na base de dados (MongoDB, 2015). Uma análise de desempenho comparando o MongoDB com outras bases de
dados é feita na Seção 3.6 com a finalidade de justificar sua escolha para este projeto.
No MongoDB, os documentos equivalem aos registros nos bancos de dados relacionais.
Para esclarecer este conceito, os trechos de código abaixo demonstrarão a estrutura, criação
e armazenamento de algumas informações.
1
2
3
4
5
Dados = {
nome: "José Carlos",
curso: "Pedagogia",
cidade: "Caicó/RN"
}
Figura 2.6: Exemplo de criação de documento com MongoDB.
Na Figura 2.6 é representada a criação de um documento denominado “Dados”que
contém três atributos: nome, curso e cidade. É possı́vel perceber que não é preciso a
inserção de regras de validação, tipos de dados ou tamanho dos atributos, garantindo
flexibilidade no armazenamento.
Outra possibilidade de representar as mesmas informações estão no trecho de código
na Figura 2.7.
Ambos os trechos registram as mesmas informações, mas contém atributos diferentes.
Já no código da Figura 2.8 é demonstrado como é possı́vel armazenar o documento criado
em um banco de dados chamado “ipsensor”.
Diante das informações supracitadas, é perceptı́vel a versatilidade na estrutura dos
dados que podem ser gerenciados pelo MongoDB, tornando-o útil para aplicações que
demandam o arquivamento de dados que podem variar sua formação e/ou que não precise
da criação de relacionamentos para representar suas informações.
16
1
2
3
4
5
Dados = {
nome: "José Carlos",
curso: "Pedagogia",
cidade:{ nome:"Caicó", estado:{"Rio Grande do Norte"}
}
Figura 2.7: Exemplo de criação de documento com MongoDB.
1
db.ipsensor.save(Dados)
Figura 2.8: Exemplo de persistência de um documento com MongoDB.
2.5
Web Services
Diante do avanço da Internet para o mercado corporativo, surgiu a necessidade de
se integrar aplicações que abrangem não apenas redes locais, mas ambientes contendo
tecnologias diferentes. A partir dessa exigência, segundo Gomes (2010), deu-se origem
a tecnologia conhecida como Web Service, tendo inı́cio em um consórcio formado por
grandes empresas tais como a IBM e Microsoft que se juntaram para unir tecnologias de
desenvolvimento Web disponı́veis na época e criar um padrão para o desenvolvimento Web
chamado de SOAP (Simple Object Acess Protocol ).
Ainda de acordo com Gomes (2010), com o desenvolvimento de Web Services podemos
desenvolver softwares capazes de interagir enviando ou recebendo informações de outros
softwares, independente da linguagem em que foram desenvolvidos, o sistema operacional
que está sendo executado ou hardware disponı́vel. Os Web Services disponibilizam toda
essa liberdade desde que a comunicação e troca de dados ocorra através do formato XML
(eXtensible Markup Language). A Figura 2.9 ilustra a interação entre a solicitação de um
cliente e a resposta de um Web Service.
Figura 2.9: Funcionamento do Web Service com SOAP.
Fonte: Adaptado de Gomes (2010).
A sequência de ações descritas na Figura 2.9 são explicadas a seguir:
1. Efetuar o download do WSDL: nesta etapa o cliente realiza o download do WSDL
(Web Services Description Language) que é um arquivo no formato XML, que tem
como finalidade descrever as informações do Web Service, assim como as operações
2.5. Web Services
17
que o compõem, definindo o formato de entrada e saı́da de dados em cada operação;
2. Enviar solicitação XML: após receber o arquivo WSDL, o cliente envia uma solicitação no formato XML realizando chamadas ao Web Service, através de seu
URI (Uniform Resource Identifier );
3. Recebe resposta XML: ao final, depois de receber a solicitação do cliente, o Web
Service realizará algum tipo de processamento e poderá ou não enviar o resultado
do processamento para o cliente, também no formato XML.
Conforme Gomes (2010), a arquitetura projetada para a transferência de mensagens
XML especifica que qualquer protocolo como HTTP, FTP, SMTP ou TCP pode ser usado, mas devido ao fato do HTTP ser dominante na Internet, ser suportado por todas
as plataformas de software e não sofrer com restrições de firewall acaba sendo o mais
empregado.
18
19
Capı́tulo 3
Desenvolvimento
“Everything should be made as simple as possible, but not simpler.”
Albert Einstein
Este Capı́tulo tem a finalidade de apresentar em detalhes os métodos, ferramentas,
experimentos e técnicas empregadas para o desenvolvimento deste trabalho.
3.1
Introdução
O desenvolvimento deste trabalho tem origem, inicialmente, nas questões relacionadas
à coleta de informações por meio de dispositivos móveis a partir de redes de computadores.
Uma de suas funcionalidades é um portscan, que será capaz de realizar a varredura em
portas de um host com o intuito de investigar o status de portas de rede. Em consequência,
será capaz de ter informações sobre a possı́vel disponibilidade de determinados serviços
em uma máquina analisada.
A implementação do portscan usará a técnica TCP connect, fazendo uso de chamadas
de sistema para realizar a conexão com o host. Outro quesito abordado por este trabalho
é a verificação da infraestrutura de uma rede de computadores usando uma ferramenta de
traçado de rotas. Esta ferramenta é capaz de descobrir por quais roteadores um pacote
atravessa na Internet até chegar a um destino especı́fico, através da utilização de um campo
presente no cabeçalho do IP, o TTL. O TTL tem a finalidade de representar o tempo de
vida de um pacote em uma rede de computadores, por meio dele é possı́vel controlar os
saltos entre roteadores de um pacote até que ele seja descartado pela rede. Além disso, é
possı́vel calcular o RTT (Round Trip Time), que é o tempo estimado para uma informação
chegar ao destinatário e o remetente receber sua confirmação (Tanenbaum, 2003).
Todos os roteadores são programados para descontar uma unidade do TTL de cada
pacote que o atravessa e, desta forma, evita que os pacotes permaneçam por um tempo
indeterminado na rede causando um tráfego desnecessário. Os dados obtidos serão armazenados por meio de um Web Service em uma base de dados MongoDB, um banco de
dados orientado a documentos que fornece uma estrutura mais flexı́vel, sem definições de
tipo ou tamanho de campos, tornando-se mais adequada para salvar os dados colhidos
por essa aplicação, disponibilizando essas informações de forma centralizada. Todas essas
funcionalidades estarão disponı́veis em um aplicativo para dispositivos móveis que estejam
executando o sistema operacional Android a partir da versão 4.1.
20
Capı́tulo 3. Desenvolvimento
3.2
Procedimentos Metodológicos
Este trabalho está constituı́do na construção de duas ferramentas que se baseiam em
informações obtidas através das redes de computadores, empregadas por meio de um
aplicativo desenvolvido na linguagem de programação Java, utilizando a plataforma de desenvolvimento Android. Para tornar possı́vel a implementação das funções dessa aplicação,
será necessário a utilização da IDE de desenvolvimento Eclipse que tem seu funcionamento
baseado em plugins, permitindo a integração com o plugin ADT (Android Developer Tools),
que facilita a execução de tarefas no desenvolvimento Android. Juntamente com o SDK
(Software Development Kit) do Android, eles fornecem os softwares necessários para a
elaboração de programas Android.
A construção do aplicativo será feita de forma modular, tornando algumas funcionalidades independentes para o uso em outras aplicações. Um dos módulos será composto
por uma biblioteca, que será responsável pelas funções de descoberta de rotas e serviços
em redes de computadores, sendo o encarregado por coletar os dados necessários. Outro
componente desta aplicação será responsável pelo armazenamento dos dados obtidos, de
modo que seja possı́vel enviar remotamente as informações obtidas. Por fim, a construção
da interface gráfica do aplicativo será feita utilizando uma GUI (Graphical User Interface)
Android, um framework de interface de usuário orientado a eventos que utiliza arquivos
XML (eXtensible Markup Language) para modelar e organizar os componentes fornecidos
pela biblioteca.
3.2.1
Caracterização da Pesquisa
A metodologia escolhida para a elaboração deste trabalho foi a abordagem Design
Science. Esta tem como objetivo a produção de conhecimento a partir da busca de soluções
para problemas do mundo real utilizando como referências as técnicas, procedimentos,
fundamentos e ferramentas que são aplicadas por profissionais de determinada área, tendo
um importante papel como meio de aproximar a teoria e prática (Aken, 2005). Como
proposta de orientação para a pesquisa, a abordagem design science se baseia em diretrizes
que devem ser seguidas a fim de se obter os resultados desejados, sendo elas:
• Tem como objeto de estudo o desenvolvimento de um artefato;
• Verificar a relevância do problema;
• Avaliação rigorosa sob o aspecto do funcionamento do artefato;
• Contribuição da pesquisa para a área de conhecimento;
• Pesquisa rigorosa sobre as técnicas a serem empregadas; e
• Uso eficiente de recursos.
Aken (2005) destaca que as formas de contribuições para um trabalho podem ser:
• Projeto do artefato: quando o artefato é uma solução para um problema que não foi
solucionado ou aplicando um conhecimento já existente a partir de uma nova visão;
• Ampliação dos fundamentos: permite que novas informações sejam adicionadas à
bases de conhecimentos já existentes, podendo estender técnicas que melhorem as
teorias, estruturas, métodos ou protótipos;
• Desenvolvimento de novas metodologias: possibilita a contribuição da pesquisa para
o desenvolvimento de novas metodologias, colaborando com a expansão da base de
conhecimento existente.
3.2. Procedimentos Metodológicos
21
Este trabalho aplicou, como forma de contribuição, o tipo projeto do artefato para o
desenvolvimento da pesquisa, já que, segundo as caracterı́sticas desse tipo, os conhecimentos para a construção do artefato em questão já existem, sendo implementado por uma
ótica diferente.
Durante o desenvolvimento deste trabalho, foram realizadas as seguintes atividades:
1. Escolha do tema;
2. Estudo bibliográfico;
3. Estudo técnico;
4. Desenvolvimento do aplicativo; e
5. Validação das ferramentas e testes.
3.2.2
Estudo Bibliográfico
O estudo bibliográfico deste trabalho ocorreu por meio de pesquisas à diversas obras
acadêmicas, com o intuito de fundamentar o trabalho, obtendo informações e conhecendo
o estado da arte nas áreas de redes de computadores, dispositivos móveis e armazenamento
de dados.
3.2.3
Estudo Técnico
A realização do estudo técnico foi feito através de informações obtidas nas documentações das tecnologias envolvidas no desenvolvimento deste trabalho (Java, Android
e MongoDB), bem como em fóruns públicos na Web, em vı́deo aulas, livros e tutoriais.
3.2.4
Desenvolvimento do Aplicativo
Após o estudo técnico, com o entendimento sobre o problema, foi possı́vel implementar
as ferramentas, envolvendo as seguintes atividades:
1. Construção da biblioteca de traçado de rotas, para que seja possı́vel verificar o
caminho percorrido por um pacote da sua origem até o destino;
2. Construção da biblioteca para o portscan, descobrindo qual o status de uma porta
lógica em um determinado endereço;
3. Desenvolvimento da classe de banco de dados com o MongoDB, sendo possı́vel realizar a persistência dos dados capturados;
4. Criação do aplicativo para o sistema operacional Android, integrando as bibliotecas
desenvolvidas e a classe de conexão com a base de dados MongoDB; e
5. Criação e configuração de um Web Service para realizar o armazenamento dos dados
na base de dados MongoDB em um servidor remoto.
3.2.5
Validação das Ferramentas e Testes
Ao final do desenvolvimento das bibliotecas e do aplicativo, para verificar e validar as
informações obtidas por elas, alguns procedimentos foram realizados. Algumas ferramentas já existentes, contendo as mesmas funcionalidades propostas pelas bibliotecas, foram
utilizadas para atestar o correto funcionamento. Estas etapas estão contidas na Seção 3.9.
Além disso, testes com o aplicativo foram feitos para certificar que o mesmo cumpre os
requisitos deste trabalho.
22
3.3
Implementação da Biblioteca PingWrapper
Nesta etapa de desenvolvimento foram realizadas atividades voltadas à construção de
uma biblioteca capaz de obter informações sobre o caminho percorrido por um pacote a
partir de um dispositivo de origem até o seu destino, utilizando um procedimento semelhante ao citado na Seção 2.3. Para isso, como principal recurso, o utilitário ping foi
empregado para que fosse possı́vel encontrar cada computador durante o caminho até o
destino.
O comando ping permite a configuração de parâmetros, tais como o número de pacotes
que serão enviados, o intervalo de tempo para o envio de um próximo pacote, um intervalo
de tempo para aguardar a resposta de um determinado alvo e o tempo de vida de um
pacote, que representa o número de saltos entre máquinas que os pacotes podem demorar
em uma rede antes de serem descartados.
Inicialmente, foi preciso realizar a modelagem da biblioteca, analisando quais informações seriam úteis para a construção deste módulo e a forma que cada uma das etapas
deveriam ser desenvolvidas. Pelo fato do funcionamento desta biblioteca para traçado de
rotas se basear na execução do comando ping e na manipulação de seus parâmetros, os
métodos responsáveis por realizar tais tarefas precisaram ser criados. Com o comando
ping ajustado, é possı́vel executá-lo para um determinado alvo informado pelo usuário e
obter informações, que dependem do tipo de resposta que será retornada pelo destino.
Como a finalidade do método para a execução do ping é apenas realizar uma chamada
ao sistema operacional para um determinado alvo e retornar o resultado obtido, se tornou
necessário a criação de um método capaz de, a partir de um comando ping, alterando o
parâmetro do tempo de vida do pacote, descobrir cada máquina pela qual o pacote passa
até chegar ao seu destino. A tarefa deste método é realizar comandos ping, incrementando
o tempo de vida do pacote em 1 até que se se consiga chegar ao destino ou que o pacote
não encontre o seu destino mesmo após percorrer um número máximo de 30 máquinas.
Objetivando determinar que um pacote chegou ao seu destino, outro método foi desenvolvido, permitindo à biblioteca encerrar a sua execução no caso encontre o endereço de
destino.
O link para o código-fonte desta biblioteca está disponı́vel no Apêndice A.4.
Após a conclusão do desenvolvimento desta biblioteca, alguns testes foram feitos a
fim de validar o seu funcionamento e a corretude do algoritmo criado. Os procedimentos
executados estão disponı́veis na Seção 3.9.
3.4
Implementação da Biblioteca PortScan
O próximo passo no desenvolvimento deste trabalho é a implementação da biblioteca
responsável por realizar os procedimentos de um portscan. A partir dos conceitos e da
técnicas demonstradas na Seção 2.2, as funcionalidades da biblioteca foram desenvolvidas
com o intuito de se obter as informações referentes ao status das portas de determinado
alvo.
Assim como na biblioteca PingWrapper, primeiramente foi preciso fazer uma análise
e modelagem dos dados com o propósito de verificar as caracterı́sticas necessárias para
o funcionamento do portscan e quais seriam suas principais funcionalidades. Devido às
3.5. Arquitetura da Aplicação
23
limitações/restrições inerentes aos privilégios que um usuário tem para criar pacotes em
estado bruto e enviá-los a um alvo para obter informações sobre o status de suas portas, a
solução encontrada para a implementação do portscan foi a utilização de sockets, através do
sistema operacional, para estabelecer uma conexão com a máquina e porta alvos enviando
uma chamada de sistema connect(). Apesar de ser mais lenta e existirem outras formas
de varredura de portas, como as citadas na Seção 2.2, esta técnica foi escolhida por ser a
mais apropriada quando não se tem privilégios de usuário.
Nesta biblioteca, as formas de varreduras de portas foram implementadas usando diferentes parâmetros. Ela é capaz de verificar todas as 216 portas disponı́veis, as 10 portas,
mais utilizadas pelos principais serviços ou entre um intervalo de portas. A biblioteca
também permite diferenciar o status retornado por cada uma das portas, ou seja, se está
aberta, fechada ou filtrada. Embora a chamada de sistema connect() não possua valor de
retorno, é possı́vel, através das formas de exceções lançadas e capturadas por blocos de
try/catch, discernir o estado de cada uma das portas.
O link para o código-fonte desta biblioteca está disponı́vel no Apêndice A.4.
3.5
Arquitetura da Aplicação
Com o proposito de exemplificar a organização dos módulos desenvolvidos e arquitetura
da aplicação, assim como o fluxo de informações contidas no aplicativo a Figura 3.1 foi
criada. Os dispositivos móveis na Figura 3.1 ilustram a execução das ferramentas de
traçado de rotas e portscan, interagindo com a Internet por meio de um ponto de acesso
sem fio para coletar informações. Da mesma forma, utilizando a Internet, as informações
são enviadas para um Web Service que recebe os dados e realiza a persistência na base de
dados MongoDB.
24
Figura 3.1: Arquitetura da aplicação.
3.6
Desenvolvimento da Classe de Conexão com o Banco de
Dados
Baseado nas informações expostas na Seção 2.4 e na análise feita a partir de métricas
contidas em Li e Manoharam (2013), que realiza um estudo sobre algumas bases de dados
para comparar caracterı́sticas e verificar quais operações tem o melhor desempenho entre
os bancos de dados analisados. A partir desta análise, a base de dados MongoDB foi
escolhida para armazenar e gerenciar as informações obtidas pelas bibliotecas PingWrapper
e PortScan.
O estudo consiste na análise de desempenho em determinadas operações, como leitura,
escrita, deletar um registro e busca por todos os registros. Contudo, de modo que a
finalidade deste trabalho tem como requisito as operações de escrita e busca de registros
3.6. Desenvolvimento da Classe de Conexão com o Banco de Dados
25
armazenados, apenas esses dois valores, juntamente com o tempo de leitura dos dados
foram analisados. Nas Tabelas 3.1, 3.2 e 3.3 são exibidos, respectivamente, os resultados
obtidos a partir de Li e Manoharam (2013) para cada uma das operações.
Base de dados/Operações
MongoDB
RavenDB
CouchDB
Cassandra
Hypertable
CouchBase
Microsoft SQL Express
10
61
570
90
117
55
60
30
50
75
898
374
160
90
76
94
100
84
1213
616
212
184
63
129
1000
387
6939
6211
1200
1035
142
1790
10000
2693
71343
67216
9801
10938
936
15588
100000
23354
740450
932038
88197
114872
8492
216479
Tabela 3.1: Tempo para escrita de n registros em milissegundos.
Fonte: Li e Manoharam (2013).
MongoDB
RavenDB
CouchDB
Cassandra
Hypertable
CouchBase
10
8
140
23
115
60
15
13
50
14
351
101
230
83
22
23
100
23
539
196
354
103
23
46
1000
138
4730
1819
2385
420
86
277
10000
1085
47459
19508
19758
3427
811
1968
100000
10201
426505
176098
228096
63036
7244
17214
Tabela 3.2: Tempo para leitura de n registros em milissegundos.
MongoDB
RavenDB
CouchDB
Cassandra
Hypertable
10
4
101
67
47
3
4
50
4
113
196
50
3
4
100
5
115
19
55
3
4
1000
19
116
173
76
5
4
10000
80
136
1063
237
25
11
100000
702
591
9512
709
159
76
Tabela 3.3: Tempo para buscar todos os n registros em milissegundos.
Diante dos resultados obtidos, foi possı́vel analisar o desempenho de cada uma das
bases de dados e compará-las. O MongoDB e CouchBase tiveram as melhores médias
para o número minimo e máximo de operações, tornando-se candidatas a serem escolhidas. Apesar da Microsoft SQL Express ter alcançado o melhor tempo de busca, não se
tornou uma opção já que é uma base de dados relacional, não se caracterizando como req-
26
uisito deste trabalho. A escolha do MongoDB se deu pelo fato do CouchBase não possuir
funcionalidade para buscar todos os registros, tornando-o inviável para utilização.
A partir dessa escolha foi implementada uma classe de conexão que possibilitou armazenar as informações de ambas as bibliotecas em um servidor remoto, utilizando um
Web Service (detalhado na Seção 3.7). Devido a facilidade de configuração deste banco
de dados, apenas algumas informações referentes ao endereço da máquina onde os dados
serão armazenados, a sua respectiva porta e o nome da base de dados foram necessárias
para que fosse possı́vel utilizá-lo.
O link para o código-fonte implementado para esta finalidade está disponı́vel no apêndice
A.
3.7
Implementação do Web Service
Diante da exigência deste trabalho para armazenar os dados coletados com as bibliotecas em um servidor remoto, surgiu a necessidade da criação de um Web Service para
executar tal tarefa. A plataforma de desenvolvimento Android não fornece uma aplicação
nativa em seu sistema operacional para enviar dados remotamente a algum servidor, tornando indispensável a criação de um Web Service para realizar a ligação entre o dispositivo
que captura as informações e a base de dados onde serão armazenadas.
Para que o Web Service funcionasse corretamente, alguns requisitos foram necessários
a fim de realizar a sua correta configuração. A princı́pio, foi preciso realizar o download e
instalação do Apache Tomcat. O Tomcat é uma aplicação que fornece um servidor Web
em Java por meio de um container, onde diversos serviços Web podem ser disponibilizados
Araújo (2010). Além disso, foi preciso a instalação do framework Apache Axis, que é um
framework de código aberto, baseado na linguagem Java e no padrão XML, utilizado para
construção de Web Service no padrão SOAP (Gomes, 2010).
Apenas algumas informações obtidas com a aplicação por meio das bibliotecas necessitam ser armazenadas e, por isso, foram criadas classes de modelo/entidade para que o
arquivo WSDL, que representa os dados e as operações no Web Service fosse construı́do
com as informações que precisam ser persistidas na base de dados MongoDB. Após a
configuração do ambiente para o Web Service com o Apache Tomcat e o Apache Axis, a
modelagem das classes para ambas as bibliotecas foram implementadas, sendo responsáveis
por enviar os dados da aplicação para o Web Service.
O procedimento utilizado para enviar os dados foi o mesmo para as duas ferramentas,
onde em cada uma foi criado um objeto do tipo SOAP que encapsula as informações e as
envia via HTTP para que o Web Service possa armazenar os dados recebidos.
O link para código-fonte desse procedimento está disponı́vel no Apêndice deste trabalho
na Seção A.4.
3.8
Desenvolvimento do Aplicativo
Neste último passo, foram realizadas as etapas voltadas para a integração de todas
as ferramentas desenvolvidas anteriormente e a criação de um aplicativo para o sistema
operacional Android que permita a utilização das bibliotecas PingWrapper e PortScan, do
Web Service e da base de dados MongoDB.
3.8. Desenvolvimento do Aplicativo
27
A criação do aplicativo consistiu, basicamente, na criação da interface gráfica, a partir
de arquivos XML, com a inserção de alguns campos de texto e botões para a interação
com o usuário. Na Figura 3.2 é ilustrada a tela inicial do aplicativo.
Figura 3.2: Tela inicial do aplicativo.
Ao selecionar um dos botões, será aberta uma tela com a respectiva funcionalidade
e o campo para que seja preenchido com o endereço IP que se deseja obter determinada
informação. Nas Figuras 3.3 e 3.4 são representadas, respectivamente, as telas das duas
ferramentas.
28
Figura 3.3: Tela do PingWrapper.
29
Figura 3.4: Tela do PortScan.
A partir do botão em cada uma dessas telas é possı́vel iniciar a execução da ferramenta
escolhida e aguardar para que o resultado seja exibido. Na Figura 3.5 é possı́vel visualizar
um exemplo de resultado da ferramenta de traçado de rotas, já na Figura 3.6 o resultado
do PortScan é exibido.
30
Figura 3.5: Exemplo de captura do PingWrapper.
31
Figura 3.6: Exemplo de captura do PortScan.
A entrada dos dados na aplicação necessitou de algumas validações para garantir o
correto funcionamento do aplicativo. Não é possı́vel iniciar nenhuma operação caso algum
dos campos estejam em branco ou contenham um formato de endereço IPv4 incorreto.
A aplicação também não será executada caso não haja conexão com a Internet, seja em
uma rede Wi-Fi ou utilizando o sinal de alguma operadora de telefonia. Na Figura 3.7 são
mostradas as mensagens de alerta do aplicativo.
32
Figura 3.7: Tela com mensagens de alerta.
3.9
Validação do Aplicativo
Ao final do desenvolvimento do aplicativo, para atestar que o mesmo funciona corretamente, alguns experimentos foram feitos para verificar a validade dos dados obtidos. Para
tal, com a finalidade de comparar os resultados, foi utilizado a ferramenta Nmap. O Nmap é
um software livre capaz de realizar portscan e é muito utilizado para avaliar segurança de
computadores e descoberta de serviços em redes de computadores (Lyon, 2012). Além dos
fatores anteriormente citados o Nmap possui também um mecanismo de traçado de rotas
e, com isso, torna-se o aplicação útil para validação do aplicativo devido a suas funcionalidades e credibilidade do software na área de redes de computadores. A validação de cada
ferramenta será feita com informações obtidas de diferentes ambientes com o intuito de
analisar o comportamento em lugares com caracterı́sticas de rede diferenciadas. Na Tabela
3.4 são listados os endereços que serão analisados nas duas ferramentas que foram gerados
de forma aleatória usando o Nmap, com o comando nmap -iR n, onde “n” é o número de
endereços a serem gerados.
Endereços IP
67.23.234.115
48.171.116.178
200.147.67.142
241.58.10.22
104.28.6.64
Tabela 3.4: Lista de endereços IP analisados.
Já nas Tabelas 3.5, 3.6, 3.7, 3.8 e 3.9 são exibidos os dados obtidos para os endereços IP
contidos na Tabela 3.4 com a captura das informações a partir da ferramenta de traçado
de rotas desenvolvida neste trabalho e com a respectiva ferramenta do Nmap em uma rede
sem restrições de firewall.
3.9. Validação do Aplicativo
33
IP 67.23.234.115
PingWrapper
Nmap
1 - 192.168.0.10 - RTT 47ms
1 - 192.168.0.10 - RTT 7.28ms
2 - 177.105.180.1 -RTT 521ms
2 - 177.105.180.1 - RTT 64.01ms
3 - 10.30.0.1 - RTT 631ms
3 - 10.30.0.1 - RTT 61.95ms
4 - 177.184.141.117 RTT 211ms 4 - 177.184.141.117 RTT 64.84ms
5 - 186.225.35.129 RTT 186ms
5 - 186.225.35.129 RTT 68.19ms
6 - 84.16.6.186 RTT 71ms
6 - 84.16.6.186 RTT 68.88ms
7 - 176.52.252.133 RTT 84ms
7 - 176.52.252.133 RTT 134.53ms
8 - 94.142.127.50 RTT 156ms
8 - 94.142.127.50 RTT 154.73ms
9 - 176.52.252.133 RTT 142ms
9 - 176.52.252.133 RTT 149.08ms
10 - 72.29.88.34 RTT 160ms
10 - 72.29.88.34 RTT 129.47ms
11 - 67.23.234.2 RTT 193ms
11 - 67.23.234.2 RTT 137.23ms
12 - 67.23.234.115 RTT 158ms
12 - 67.23.234.115 RTT 139.27ms
Tabela 3.5: Comparação de captura para o endereço 67.23.234.115 em uma rede sem restrições
de firewall.
IP 48.171.116.178
PingWrapper
Nmap
1 - 192.168.0.10 - RTT 66ms
1 - 192.168.0.10 - RTT 2.30ms
2 - 177.105.180.1 - RTT 55ms
2 - 177.105.180.1 - RTT 51.26ms
3 - 10.30.0.1 - RTT 110ms
3 - 10.30.0.1 - RTT 51.21ms
4 - 177.184.141.117 - RTT 79ms
4 - 177.184.141.117 RTT 52.73ms
5 - 186.225.35.129 - RTT107 ms
5 - 186.225.35.129 - RTT 61.14ms
6 - 186.230.231.161 - RTT 122ms 6 -186.230.231.161 - RTT 95.84ms
7 - ***
7 - ***
..
.
30 - ***
30 - ***
de firewall.
34
IP 69.164.223.115
PingWrapper
Nmap
1 - 192.168.0.10 - RTT 74ms
1 - 192.168.0.10 - RTT 9.81ms
2 - 177.105.180.1 - RTT 60ms
2 - 177.105.180.1 - RTT 22.94ms
3 - 10.30.0.1 - RTT 84ms
3 - 10.30.0.1 - RTT 21.72ms
4 - 177.184.141.117 - RTT 53ms
4 - 177.184.141.117 RTT 24.76ms
5 - 186.225.35.129 - RTT 72ms
5 - 186.225.35.129 - RTT 29.07ms
6 - 84.16.6.186 - RTT 58ms
6 - 84.16.6.186 - RTT 31.07ms
7 - 176.52.254.22 - RTT 73ms
7 - 176.52.254.22 - RTT 28.26ms
8 - 94.142.123.234 - RTT 121ms
8 - 94.142.123.234 - RTT 97.79ms
9 - 94.142.126.161 - RTT 163ms
9- 94.142.126.133 - RTT 126.89ms
10 - 173.205.48.49 - RTT 167ms
10 - 129.250.9.1 - RTT 119.15ms
11 - 129.250.4.205 - RTT151 ms
11 - 129.250.4.205 - RTT 136.57ms
12 - 129.250.203.106 - RTT 164ms 12 - 69.31.34.178 - RTT 156.05ms
13 - ***
13 - ***
14 - 207.99.53.42 - RTT 190ms
14 - ***
15 - 69.164.223.115 - RTT 402ms
15 - ***
16 - ***
17 - ***
18 - ***
19 - ***
20 - ***
21 - ***
22 - ***
23 - 69.164.223.115 - RTT 3.88ms
de firewall.
IP 241.58.10.22
PingWrapper
Nmap
1 - 192.168.0.10 - RTT 67ms
1 - 192.168.0.10 - RTT 3.39ms
2 - 177.105.180.1 - RTT 1030ms
2 - 177.105.180.1 - RTT 35.70ms
3 - 10.30.0.1 - RTT 667ms
3 - 10.30.0.1 - RTT 35.60ms
4 - 177.184.141.117 - RTT 303ms 4 - 177.184.141.117 RTT 36.28ms
5 - ***
5 - ***
..
.
30 - ***
30 - ***
Tabela 3.8: Comparação de captura para o endereço 241.58.10.22 em uma rede sem restrições de
firewall.
35
IP 104.28.6.64
PingWrapper
Nmap
1 - 192.168.0.10 - RTT 45ms
1 - 192.168.0.10 - RTT 2.32ms
2 - 177.105.180.1 - RTT 43ms
2 - 177.105.180.1 - RTT 21.26ms
3 - 10.30.0.1 - RTT 49ms
3 - 10.30.0.1 - RTT 21.24ms
4 - 177.185.141.117 - RTT 78ms 4 - 177.185.141.117 - RTT 22.40ms
5- 186.225.35.129 - RTT ms
5- 186.225.35.129 - RTT 30.67ms
6 - 84.16.6.186 - RTT ms
6 - 84.16.6.186 - RTT ms
7 - 176.52.254.22 - RTT ms
7 - 176.52.254.22 - RTT ms
8 - 94.142.127.57 - RTT ms
8 - 94.142.127.57 - RTT ms
9 - 176.52.255.33 - RTT ms
9 - 176.52.255.33 - RTT ms
10 - 176.52.253.23 - RTT ms
10 - 176.52.253.23 - RTT ms
11 - 104.28.6.64 - RTT ms
11 - 104.28.6.64 - RTT ms
Tabela 3.9: Comparação de captura para o endereço 104.28.6.64 em uma rede sem restrições de
firewall.
É possı́vel verificar que alguns endereços se diferem nas rotas contidas, assim como as
próprias rotas podem mudar, comparando as duas ferramentas, como ocorreu nas rotas da
Tabela 3.7. Outro ponto a ser analisado é a situação em que alguns roteadores responderam
apenas para uma das ferramentas, como pode-se verificar na também nas rotas da Tabela
3.7. Essas alterações podem se explicadas pelo fato do pacote enviado por cada ferramenta
ter seguido por caminhos diferentes ou na situação em que alguns endereços IP respondem
pelo mesmo computador que esteja contido na rota.
As capturas obtidas dentro de um ambiente de rede com regras de firewall são apresentadas nas Tabelas 3.10, 3.11, 3.12, 3.13 e 3.14.
IP 67.23.234.115
PingWrapper
Nmap
1 - 10.142.68.1 - RTT 111ms 1 - 10.142.68.1 - RTT 38.15ms
2 - 10.142.255.1 - RTT 29ms 2 - 10.142.255.1 - RTT 39.19ms
3 - 192.168.1.1 - RTT 28ms
3 - 192.168.1.1 - RTT 26.23ms
4 - ***
4 - ***
..
.
30 - ***
30 - ***
Tabela 3.10: Comparação de captura para o endereço 67.23.234.115 em uma rede com restrições
de firewall.
36
IP 48.171.116.178
PingWrapper
Nmap
1 - 10.142.68.1 - RTT 40ms
1 - 10.142.68.1 - RTT 86.51ms
2 - 10.142.255.1 - RTT 34ms 2 - 10.142.255.1 - RTT 99.24ms
3 - 192.168.1.1 - RTT 37ms
3 - 192.168.1.1 - RTT 87.26ms
4 - ***
4 - ***
..
.
30 - ***
30 - ***
de firewall.
IP 200.147.67.142
PingWrapper
Nmap
1 - 10.142.68.1 - RTT 40ms
1 - 10.142.68.1 - RTT 8.08ms
2 - 10.142.255.1 - RTT 33ms 2 - 10.142.255.1 - RTT 15.55ms
3 - 192.168.1.1 - RTT 40ms
3 - 192.168.1.1 - RTT 10.61ms
4 - ***
4 - ***
..
.
30 - ***
30 - ***
de firewall.
IP 241.58.10.22
PingWrapper
Nmap
1 - 10.142.68.1 - RTT 51ms 1 - 10.142.68.1 - RTT 12.60ms
2 - ***
2 - ***
3 - 192.168.1.1 - RTT 51ms 3 - 192.168.1.1 - RTT 14.36ms
4 - ***
4 - ***
..
.
30 - ***
30 - ***
de firewall.
37
IP 104.28.6.64
PingWrapper
Nmap
1 - 10.142.68.1 - RTT 36ms
1 - 10.142.68.1 - RTT 8.27ms
2 - 10.142.255.1 - RTT 34ms 2 - 10.142.255.1 - RTT 13.72ms
3 - 192.168.1.1 - RTT 32ms
3 - 192.168.1.1 - RTT 10.66ms
4 - ***
4 - ***
..
.
30 - ***
30 - ***
de firewall.
Com os resultados obtidos nas comparações das capturas realizadas dentro de uma
rede com firewall exibidas nas Tabelas 3.10, 3.11, 3.12, 3.13 e 3.14 é possı́vel perceber
que as ferramentas só conseguiram ter alguma resposta, para todos os endereços alvo, nos
três primeiros roteadores. Esse cenário pode ter se apresentado devido a bloqueios feitos
nos roteadores desta rede para não responderem a comandos ping, filtrando qualquer
solicitação desta natureza.
Com o portscan, a validação foi feita a partir da mesma lista de endereços IP da tabela
3.4 além de usar as n portas mais utilizadas de acordo com o arquivo “nmap-services”[i] ,
que fornece uma lista com a frequência de utilização de cada porta. Essas portas foram
usadas para efeito de comparação entre o portscan implementado neste trabalho com o do
Nmap. Assim como na validação com a ferramenta de traçado de rotas, este experimento
será realizado em redes de computadores distintas no que se refere as configurações e
restrições de cada uma.
Na Tabela 3.15 são descritas as portas nas quais a varredura foi realizada com as duas
ferramentas.
Porta
80
631
161
137
123
138
1434
445
135
67
Serviço
HTTP (Procolo de transferência de HiperTexto)
Protocolo de impressão na internet
Protocolo simples de gerenciamento de rede
Serviço NetBIOS
Protocolo de tempo na rede
Serviço de datagrama NetBIOS
Monitor Microsoft SQL
Serviços de diretório Microsoft
Microsoft RPC Serviço de localização
DHCP (Protocolo de configuração dinâmica do Host)
Tabela 3.15: Lista de portas analisadas.
Após a varredura das portas descritas na Tabela 3.15 com os mesmos endereços IP
[i]
Disponı́vel em https://svn.nmap.org/
38
contidos na Tabela 3.4, foram obtidos os resultados expostos nas Tabelas 3.16, 3.17, 3.18,
3.19 e 3.20.
Porta
80
631
161
137
123
138
1434
445
135
67
IP 67.23.234.115
Status Portscan Status Nmap
Aberta
Aberta
Filtrada
Filtrada
Filtrada
Filtrada
Filtrada
Filtrada
Filtrada
Filtrada
Filtrada
Filtrada
Filtrada
Filtrada
Filtrada
Filtrada
Filtrada
Filtrada
Filtrada
Filtrada
Tabela 3.16: Comparação entre ferramentas portscan para o endereço 67.23.234.115.
Porta
80
631
161
137
123
138
1434
445
135
67
IP 48.171.116.178
Filtrada
Filtrada
Filtrada
Filtrada
Filtrada
Filtrada
Filtrada
Filtrada
Filtrada
Filtrada
Filtrada
Filtrada
Filtrada
Filtrada
Filtrada
Filtrada
Filtrada
Filtrada
Filtrada
Filtrada
Porta
80
631
161
137
123
138
1434
445
135
67
IP 200.147.67.142
Aberta
Aberta
Filtrada
Filtrada
Filtrada
Filtrada
Filtrada
Filtrada
Filtrada
Filtrada
Filtrada
Filtrada
Filtrada
Filtrada
Filtrada
Filtrada
Filtrada
Filtrada
Filtrada
Filtrada
Porta
80
631
161
137
123
138
1434
445
135
67
IP 241.58.10.22
Filtrada
Filtrada
Filtrada
Filtrada
Filtrada
Filtrada
Filtrada
Filtrada
Filtrada
Filtrada
Filtrada
Filtrada
Filtrada
Filtrada
Filtrada
Filtrada
Filtrada
Filtrada
Filtrada
Filtrada
39
40
Porta
80
631
161
137
123
138
1434
445
135
67
IP 104.28.6.64
Aberta
Aberta
Filtrada
Filtrada
Filtrada
Filtrada
Filtrada
Filtrada
Filtrada
Filtrada
Filtrada
Filtrada
Filtrada
Filtrada
Filtrada
Filtrada
Filtrada
Filtrada
Filtrada
Filtrada
Pelo fato das análises nas redes com restrições e sem restrições retornarem exatamente
as mesmas informações, nas Tabelas 3.16, 3.17, 3.18, 3.19 e 3.20 são representados os
resultados dos dois ambientes.
41
Capı́tulo 4
Considerações Finais
“Intellectual growth should commence
at birth and cease only at death.”
Albert Einstein
4.1
Conclusão
A realização deste trabalho teve como caracterı́stica principal o desenvolvimento de um
aplicativo para dispositivos móveis que executem o sistema operacional Android a partir da
versão 4.1, contendo ferramentas voltadas a área de redes de computadores. Durante este
trabalho foi possı́vel adquirir conhecimentos quanto à estrutura de uma aplicação Android,
mecanismos de descoberta de rotas e serviços, procedimentos envolvendo a comunicação
e armazenamento de dados de forma remota e de tecnologias relacionadas a cada uma
dessas áreas. Todas estas atividades proporcionaram uma proveitosa experiência, visto que
englobaram domı́nios sobre campos de atuação tanto no que se refere ao desenvolvimento
de sistemas quanto relacionados a rede de computadores.
Conclui-se que as atividades deste projeto e objetivos planejados antes e durante seu
andamento foram desempenhados de forma satisfatória, mostrando a relevância do trabalho nas áreas tecnológicas envolvidas, das quais se destacam o desenvolvimento para
dispositivos móveis e redes de computadores. O artefato desenvolvido neste trabalho pode
ser usado como base para criação de uma ferramenta mais complexa, auxiliando na elaboração de novos estudos sobre os temas e integrações com outras aplicações.
Como legado, permanece o fato de se ter desenvolvido uma aplicação útil para profissionais na área de redes de computadores permitindo, além das funcionalidades de traçado
de rotas e descoberta de serviços, a mobilidade de realizar estas ações sem a necessidade
de portar um computador pessoal.
Por fim, algumas limitações foram enfrentadas durante a realização deste trabalho,
tendo como principais obstáculos a construção do aplicativo sem a necessidade de permissões para super usuário e a minimização do tempo de execução do aplicativo já que,
por não ter privilégios, utiliza técnicas que demandam mais tempo para serem concluı́das.
Outra dificuldade encontrada foi o envio das informações obtidas com o aplicativo para um
servidor remoto, dado que o sistema operacional Android não possui nenhum aplicativo
nativo que permita esse tipo de ação.
42
Capı́tulo 4. Considerações Finais
4.2
Contribuições
Como contribuições deste trabalho tem-se uma aplicação com funcionalidades voltadas
para a descoberta de rotas e serviços em redes de computadores, capaz obter e armazenar
as informações coletadas em um servidor remoto, integrando-as em um aplicativo para
dispositivos móveis que executem o sistema operacional Android. As funcionalidades desenvolvidas para o traçado de rotas e descoberta de serviços foram implementadas para
que seja possı́vel utilizá-las de forma independente em outras aplicações.
Além disso, este trabalho também contribui com o mecanismo de armazenamento dos
dados utilizados neste projeto, onde o desenvolvimento de um Web Service foi necessário
para intermediar a comunicação entre o aplicativo e a base de dados, visto que a plataforma
de desenvolvimento Android não fornece nenhuma aplicação nativa para este fim. O
aplicativo elaborado neste trabalho fornece ferramentas úteis para a área de redes de
computadores juntamente com a mobilidade fornecida pelos dispositivos móveis.
4.3
Trabalhos Futuros
Para trabalhos futuros existem algumas tarefas que podem ser implementadas, seja
para aperfeiçoamento do aplicativo criado, para implementação de novas funcionalidades
ou integração com outras ferramentas. No que se refere ao aperfeiçoamento do aplicativo
pode-se realizar melhorias em sua interface gráfica, adicionando elementos que favoreça a
visualização dos dados pelos usuários. Para o desenvolvimento de novas funcionalidades
e integração com outras ferramentas tem-se a ideia de implementar uma interface gráfica
para um sistema desktop fazendo uso das bibliotecas construı́das neste trabalho.
Por fim, outra tarefa que poderia ser implementada é a composição das rotas e descobertas de serviços a partir das informações obtidas com as bibliotecas desenvolvidas
neste trabalho. Seria possı́vel obter uma visualização intuitiva de cada uma das rotas,
além das informações sobre a disponibilidade de serviços em cada um dos roteadores contidos na rota, assemelhando-se as funcionalidades da ferramenta Zenmap[i] , que funciona
como a interface gráfica da ferramenta Nmap. O Zenmap integra uma ferramenta de rede
denominada RadialNet[ii] , que é a responsável por gerar estruturas de redes mapeadas
pelo Nmap, proporcionando uma visão gráfica dos dispositivos em uma rede (Medeiros e
Santos, 2009) . Na Figura 4.1, é exibido a composição de rotas a partir das informações
geradas pela ferramenta Zenmap através dos dados obtidos pelo Nmap.
[i]
[ii]
Disponı́vel em https://nmap.org/zenmap/
Disponı́vel em https://github.com/labepi/radialnet
4.3. Trabalhos Futuros
43
Figura 4.1: Exemplo de composição de rotas com o Zenmap.
44
Capı́tulo 4. Considerações Finais
45
Apêndice A
Apêndice para Desenvolvedor
Neste Apêndice, serão apresentadas as ferramentas, bibliotecas e configurações necessárias
para o desenvolvimento de uma aplicação Android utilizando a IDE para desenvolvimento
Eclipse, de acordo com a ordenação necessária e de forma genérica, sem evidenciar nenhum sistema operacional. Na Seção A.1, são expostas informações sobre a origem, caracterı́sticas da plataforma de desenvolvimento Android e as motivações para sua criação.
Na Subseção A.1.1, a arquitetura Android é detalhada, exibindo cada funcionalidade e
descrevendo como cada parte desse modelo pode ser utilizada. Os Componentes de uma
Aplicação Android são descritos na Subseção A.1.2, explicando a importância de cada um
para o correto desenvolvimento de um aplicativo Android.
Na Seção A.2, a preparação do ambiente de desenvolvimento é demonstrada, na Subseção
A.2.1, com a configuração do JDK (Java Development Kit) e do SDK (Software Development Kit), exibida na Subseção A.2.2. A Subseção A.2.3 demonstra os passos necessários
para a configuração que permita o desenvolvimento de aplicativos Android. A seguir,
na Seção A.3 são apresentados os aspectos relacionados ao plugin ADT para o Eclipse e
ao AVD, gerenciador de dispositivos virtuais para a execução de aplicativos, mostrados,
respectivamente, nas Subseções A.3.1 e A.3.2.
A.1
Android
O Android é um Sistema Operacional (SO) voltado para dispositivos móveis, baseado
no kernel Linux e atualmente é mantido pela Google . O SO é voltado para a interação
direta com os usuários através de telas sensı́veis ao toque e, nos dias de hoje, é utilizado,
principalmente, na nova geração de telefones celulares, os smartphones. A tecnologia
Android também está presente em tablets, relógios e até em veı́culos, integrando vários
dispositivos em uma mesma plataforma.
Outras linguagens de programação, tais como Windows Mobile e Java ME existiam
antes do aparecimento do Android, mas não obtiveram grande sucesso em virtude das
restrições de hardware existentes, softwares proprietários e bloqueio por parte das fabricantes para a inclusão de aplicativos de terceiros. Parte desses problemas foi solucionado
com o surgimento dos smartphones. Os smartphones é o principal alvo do sistema operacional da Google, já que com o avanço tecnológico esses aparelhos se tornaram verdadeiros
computadores pessoais devido ao seu alto poder de processamento, conectividade com a
Internet e a integração de vários recursos, como sensores de movimento, câmera e GPS.
Outro ponto positivo é o seu modelo de código-fonte aberto, que concede tanto aos de-
46
Apêndice A. Apêndice para Desenvolvedor
senvolvedores comuns quantos as grandes fabricantes a permissão para realizar alterações
no sistema, personalizando-o de acordo com cada necessidade. Um dos fatores que alavancaram o desenvolvimento para Android é a concessão, por parte do SO, de todo o
hardware e aplicativos nativos para a criação de novas aplicações. O serviço de mapas do
Google, calendário, agenda, câmeras e sensores são alguns dos recursos disponı́veis para a
integração em novos aplicativos desenvolvidos.
Apesar de aparentar ser mais recente, o Android foi construı́do, inicialmente, por uma
pequena empresa denominada Android Inc., situada na Califórnia, EUA, ganhando maior
visibilidade a partir da sua compra pela Google, junto com a formação da Open Handset Alliance (Aliança de Telefonia Móvel Aberta), um grupo de empresas de telefonia e
fabricantes de hardware e o lançamento do SDK (Kit de Desenvolvimento de Software)
fazendo com que a tecnologia Android se disseminasse rapidamente entre os desenvolvedores. Poucos meses após o lançamento, mais de um milhão de downloads do SDK foram
feitos, mesmo estando em versão beta (Rogers et al., 2009). O Android é uma plataforma
para desenvolvimento de dispositivos móveis robusta e de fácil utilização, visto que a
construção de aplicativos é baseada na linguagem de programação Java e na criação de
arquivos XML para desenvolvimento da interface gráfica.
A.1.1
Arquitetura Android
A infraestrutura do Android é baseada em uma pilha contendo um sistema operacional
baseado em Linux, um conjunto de bibliotecas, a API Android Runtime e aplicações
nativas (Ogliari e Brito, 2014). As bibliotecas contidas na pilha Android consistem em
componentes desenvolvidas na linguagem C/C++ e estão disponı́veis para desenvolvedores
utilizarem em funções distintas. A pilha de bibliotecas Android é ilustrada na Figura A.1
Figura A.1: Arquitetura em camadas no Android.
Fonte: Ogliari e Brito (2014).
Na parte superior da Figura A.1 estão as aplicações. O Android vem com diversos programas de uso comum instalados, como calendário, cliente de e-mail, navegadores
A.1. Android
47
e contatos. Todas essas aplicações nativas são escritas em Java, da mesma forma que
aplicações desenvolvidas por terceiros, ou seja, é possı́vel desenvolver novos aplicativos
utilizando recursos como câmera e GPS ou aproveitar os aplicativos já existentes, como
envio de e-mails, mensagens de texto ou executar músicas para criar novos aplicativos.
Do mesmo modo que em Java, no Android, as aplicações são executadas em máquinas
virtuais, onde cada máquina executa independente das demais aplicações, mas permitem
o compartilhamento dos dados entre as instâncias das máquinas virtuais e das aplicações
vinculadas entre elas. Logo após, na camada abaixo, estão lozalizados os frameworks
de aplicação. Por ser uma plataforma aberta o Android permite aos usuários usar o
hardware disponı́vel nos aparelhos e executar tarefas em segundo plano, enviar mensagens
e outras diversas funcionalidades acessı́veis aos desenvolvedores da mesma forma que estão
disponı́veis paras os fabricantes.
A seguir, estão as bibliotecas que fornecem funcionalidades para todas as aplicações.
O Android dispõe de várias bibliotecas, tais como a OpenCORE, para a exibição e manipulação de arquivos multimı́dIa, a SQLite, usada para operações em bancos de dados e a
OpenGL para renderização de imagens em 3 dimensões. Em uma mesma camada, ao lado,
está o Android Runtime. Essa é a parte responsável pelo gerenciamento das máquinas virtuais acessando o kernel do Linux para gerenciar os recursos com mais eficiência. Na
última camada está o núcleo da arquitetura, o kernel do Linux que, por questão de segurança, é fechada para os desenvolvedores. Essa camada tem a atribuição de realizar o
gerenciamento de memória, processos e por mediar a comunicação entre software e hardware.
A.1.2
Componentes de uma Aplicação Android
A construção de aplicativos Android se difere da forma de desenvolvimento de aplicações
Desktop e Web. Essas diferenças são conduzidas por conceitos especı́ficos da própria
plataforma e de caracterı́sticas particulares dos dispositivos móveis. Quatro componentes
principais estão disponı́veis para o desenvolvedor, cada um com propriedades diferentes e
possibilidades de aplicações distintas, seja com ou sem interface gráfica, funcionando em
segundo plano ou apenas monitorando atividades em execução.
O primeiro e mais importante componente no desenvolvimento Android é a Activity. A
Activity é responsável por gerenciar uma tela de aplicação e mostrar uma interface gráfica
ao usuário permitindo, através disso, controlar a interação entre o usuário e o sistema
por meio de uma tela, normalmente sensı́vel ao toque, simulando botões virtuais ou com
botões fı́sicos do aparelho. Em uma aplicação Android, podem existir várias Activitys que
se comunicam entre si e podem também iniciar uma Activity em outra aplicação.
Uma simples demonstração da interação desses componentes é quando um usuário, por
exemplo, está assistindo um vı́deo no aplicativo do Youtube e deseja compartilhá-lo no
Facebook. Isso é feito a partir de uma Activity do Youtube que invoca uma Activity no
aplicativo do Facebook, usando as informações referentes ao vı́deo que se deseja compartilhar. Mesmo tendo várias Activitys em uma mesma aplicação, somente uma é ativada
por vez, sendo assim, ao iniciar uma nova Activity, as antigas são paradas e colocadas em
segundo plano até que o usuário volte e ative-a novamente. Todos esses procedimentos
formam o ciclo de vida de uma Activity.
Outro componente que pertence ao ciclo de desenvolvimento Android chama-se Service. O Service tem como objetivo permitir a uma aplicação executar tarefas em segundo
plano. Diferindo das Activitys, os Services não possuem interface gráfica e são capazes
48
de executar mesmo após uma aplicação ter sido encerrada. Ao ser iniciada, um Service,
em segundo plano, estará funcionando para que outros componentes possam se conectar
e obter informação providas por ele. Um exemplo de implementação de Services é um
reprodutor de músicas que, mesmo em segundo plano, deve continuar a reproduzir os
arquivos escolhidos, até que tenha sua execução interrompida pelo usuário.
O terceiro componente disponı́vel para o desenvolvedor é o Content Provider. Ele é
responsável por salvar, gerenciar e disponibilizar um determinado conjunto de dados em
comum que são usados entre aplicações. Alguns Content Provider são nativos do Android,
fornecendo um grupo de dados que pode ser acessado por qualquer aplicação. Um tipo de
dado que pode ser compartilhado são as informações sobre os contatos, no qual podem ser
usados em aplicações como e-mails, mensagens de texto ou até mesmo em ligações. Apesar
da disponibilidade de Content Providers provenientes da próprio Android, é possı́vel criar
novos provedores de conteúdo, capazes de partilhar os dados gerados com outras aplicações.
A criação de um Content Provider não é obrigatória, a não ser que se deseje compartilhar os dados armazenados. A execução de um Content Provider pode ser comparada a
um banco de dados relacional. Em sua estrutura, os dados são armazenados em tabelas
e consultados através de um componente chamado Content Resolver, retornando as informações solicitadas. Caso precise implementá-lo ou utilizá-lo, é necessário programar os
métodos para cada ação correspondente, sendo eles: query(), insert(), update() e delete().
Por fim, o ultimo componente definido pela arquitetura Android é o Broadcast Receiver.
Esse componente tem a finalidade de receber e processar eventos gerados pelo sistema e
compartilhá-los com todas as aplicações. A partir dele, aplicações podem capturar o evento
que foi criado e realizar ações em conformidade com tais eventos. Diversos eventos podem
ser gerados pelo sistema.
Um alerta de conexão a uma rede sem fio, bateria fraca, indicação de chamadas de
voz ou mensagens são exemplos de Broadcast Receiver. Esses avisos podem ser gerados
pelo próprio Android ou por outras aplicações em eventos especı́ficos, como, por exemplo,
o término de um Download que pode ser de interesse de uma determinada aplicação e
ela pode, através de um Broadcast Receiver, receber esse evento ainda que não tenha sido
gerada por um serviço nativo.
A.2
Ambiente de Desenvolvimento
Nas Subseções a seguir, serão descritos conceitos sobre o JDK e SDK, kits de desenvolvimento necessários para o correto funcionamento do ambiente de desenvolvimento na
plataforma Android.
A.2.1
JDK
O JDK (Java Development Kit), é um utilitário com a finalidade de permitir a criação
de jogos, programas e aplicativos para a plataforma Java. Atualmente, o JDK é mantido
pela empresa de tecnologia Oracle e, mesmo sendo proprietário, ainda é um software de
código aberto que é mantido pela comunidade de usuários. O JDK é composto pelo
compilador e pelas bibliotecas necessárias para criação de programas em Java, contendo
também ferramentas para testes dos programas desenvolvidos. Caso o sistema operacional
que executará a aplicação não tenha uma máquina virtual Java, o JDK fará a a instalação.
Além disso, o JDK fornece um arquivo executável que realiza todo o trabalho de instalação
A.3. Configuração do Ambiente Android
49
e configuração do ambiente.
A.2.2
Android SDK
O Android SDK (Software Development Kit) é um pacote de software que fornece os
itens fundamentais para o desenvolvimento na plataforma Android. Nele estão inclusos
diversas APIs desenvolvidas para controlar as funções do dispositivo, bem como realizar
a integração de serviços. O SDK do Android é estruturado por um conjunto de arquivos
compostos por: bibliotecas, executáveis, scripts, documentos e ferramentas (Mednieks
et al., 2012). O Android SDK fornece ainda um emulador para o testar as aplicações e toda
a documentação necessária para o desenvolvimento. Por padrão, o SDK não inclui todas
as ferramentas para iniciar a criação de aplicações, cabendo ao desenvolvedor adicionar ao
SDK os utilitários que cada projeto precisa.
A.2.3
Eclipse IDE
A IDE (Integrated Development Environment) Eclipse é uma plataforma de tecnologia
de finalidade geral, que pode ser usada para a criação de aplicações utilizando diversos
SDK. Apesar de geralmente ser utilizado para a implementação, testes e depuração de
softwares em Java, o Eclipse suporta outras linguagens como C/C++ e PHP através da
emulação de um ambiente de programação utilizando módulos de extensão. Uma das
vantagens do ambiente é que seu desenvolvimento é baseado em plugin, aumentando o
suporte ao desenvolvedor, oferecendo diversas opções para criação de projetos, inclusive
de aplicações Android com o plugin ADT (Android Developer Tools).
A.3
Configuração do Ambiente Android
Nesta Seção, serão detalhadas questão inerentes a configuração do plugin ADT (Android Developer Tools) no ambiente de desenvolvimento Eclipse para a adição de recursos
do Android em projetos e a criação de um AVD(Android Virtual Device), que permita a
execução de aplicações simulando o sistema operacional do Android em uma determinada
versão, criando um dispositivo móvel virtual.
A.3.1
ADT
De modo que a IDE Eclipse tem seu desenvolvimento voltado para plugin, é necessária
a inclusão e configuração do plugin ADT para permitir a criação de aplicações Android. O
plugin ADT possibilita que o Eclipse possa compilar aplicativos para o Android, bem como
instânciar o emulador do Android e permitir a edição de aquivos XML, responsáveis pela
interface gráfica das aplicações. As imagens a seguir ilustrarão os passos essenciais para a
correta configuração do Eclipse, preparando o ambiente para a execução de projetos.
Inicialmente, abra o Eclipse e acesse o menu Help, New Software. Ao abrir a janela,
clique no botão Add para adicionar a referência para o download do ADT, como é apresentado na Figura A.2.
Na janela seguinte, digite “ADT Plugin” no campo referente ao nome e informe o
endereço “https://dl-ssl.google.com/android/eclipse/” no campo URL. Feito isso, clique
em OK para que os repositórios de plugins sejam adicionados ao Eclipse. O processo é
ilustrado na A.3.
50
Figura A.2: Download do plugin ADT para Eclipse.
Figura A.3: Download do plugin ADT para Eclipse.
Selecione o repositório ADT plugin no campo Work with e marque as opções Developer
Tools e NDK Plugins na lista que será carregada logo abaixo e clique em Next para
continuar, assim como é exibido na Figura A.4
A imagem seguinte representa, através da Figura A.5, a ultima etapa do processo
de configuração. Após prosseguir a instalação, será exibido os componentes que serão
instalados. Clique em Next para continuar e, após isso, aceite os termos de licença para
concluir a instalação.
Ao termino de todas essas etapas, o Eclipse estará configurado para a criação de
aplicações Android.
A.3.2
AVD
O SDK da plataforma de desenvolvimento Android fornece um emulador que permite
simular dispositivos executando um sistema operacional Android, para realizar testes nas
A.3. Configuração do Ambiente Android
51
Figura A.4: Diálogo Install do Eclipse mostrando o plugin Android para download.
Figura A.5: Lista de componentes a serem instalados.
aplicações em um computador. Um AVD (Android Virtual Device) virtualiza um ambiente
Android, possibilitando a configuração de parâmetros para viabilizar a estrutura necessária
para o desenvolvimento em uma versão especı́fica do sistema operacional Android. Algumas propriedades como tamanho da tela, capacidade de memória e armazenamento podem
ser realizadas na organização de um AVD.
Após ter realizado a integração do plugin ADT com a IDE Eclipse, demonstrada na
Subseção A.3.1, já é possı́vel realizar a criação de um ambiente virtual utilizando o AVD
Manager, como é mostrado na Figura A.6.
Ao clicar no botão New, a tela ilustrada na Figura A.7 é exibida, na qual devem ser
inseridos os parâmetros que especificam o novo AVD.
1. Name: Pode ser inserido qualquer nome para o AVD, mas sugere-se que seja identificado com a versão do Android escolhida;
2. Target: Define qual imagem do sistema será usada. Ela deve ser a mesma, ou mais
52
Figura A.6: Gerenciador AVD.
recente que a versão dos projetos a serem executados;
3. SD Card : Caso o aplicativo a ser executado precise de um maior armazenamento, a
opção pode ser preenchida com o tamanho de memória correspondente a necessidade
do projeto;
4. Skin: Determina as configurações referentes ao tamanho da tela do dispositivo a ser
emulado. Sugere-se que algumas resoluções diferentes sejam testadas para verificar se
os componentes da interface gráfica do aplicativo funcionam em definições distintas;
A.4
Repositório
Esta Seção reune os links referentes aos códigos-fonte desenvolvidos neste trabalho e do
executável para instalação em um dispositivo executando o sistema operacional Android.
Os códigos fonte do aplicativo desenvolvido neste trabalho, bem como das bibliotecas
desenvolvidas para o propósito deste projeto estão disponı́veis no link:
- https://github.com/tuliovianna/ipsensor.git
Após o download, o instalador do aplicativo “IpSensor.apk” pode ser obtido dentro do
diretório “bin” e transferido para o dispositivo desejado.
O código fonte do Web Service está disponı́vel no link:
- https://github.com/tuliovianna/web-service.git
A.5. Execução do Aplicativo
53
Figura A.7: Criação de um novo AVD.
A.5
Execução do Aplicativo
Durante o desenvolvimento do aplicativo, foi necessário executá-lo diversas vezes a fim
de testar suas funcionalidades e possı́veis erros. Para isso, o Eclipse fornece a possibilidade
da criação de emuladores para simular um dispositivo Android real em um ambiente de
desenvolvimento. Contudo, devido a alta quantidade de recursos computacionais consumidos pelos emuladores, a utilização dos mesmos se torna inviável pela lentidão na execução
de aplicativos e pelas restrições de hardware como, por exemplo, a utilização da própria
interface de rede do computador que está emulando a aplicação.
Para solucionar este problema, foi utilizado um smartphone executando o sistema operacional Android como meio para a execução da aplicação. Para isso, foi preciso conectar
o dispositivo Android via USB ao computador onde o software está sendo construı́do e ativar o modo de depuração no dispositivo. Essa opção é normalmente encontrada seguindo
o caminho Configuração, seguido por Opções do Desenvolvedor. Após o dispositivo ser
configurado, a instalação do aplicativo é feita selecionando o projeto desejado e escolhendo
o aparelho que deseja-se fazer a instalação. Na Figura A.8 são ilustrados os procedimentos
anteriormente citados.
54
Figura A.8: Configuração para o modo de desenvolvimento no dispositivo.
55
Aken, Joan Ernst Van (2005), Management research as a design science: Articulating the
research products of mode 2 knowledge production in management, em ‘British Journal
of Management’, pp. 19–36.
(Citado na página 20)
Araújo, Everton Coimbra (2010), Desenvolvimento para Web com Java, Visual Books.
(Citado nas páginas 2 e 26)
Association, GSMA (2014), ‘The Mobile Economy 2014’, GSMA Mobile Economy 2(1), 2–
3.
Banker, Kyle (2011), MongoDB IN ACTION, Manning.
Brito, Samuel H. B. (2013), IPv6 - O novo protocolo da Internet, 1a edição, Novatec
Editora.
Deering, S. e R. Hinden (1998), ‘Internet Protocol, Version 6 (IPv6)’. Tornou obsoleta a
RFC 2373.
URL: https://www.ietf.org/rfc/rfc2460.txt
Deitel, Paul, Abbey Deitel, Harvey Deitel e Michael Morgano (2012), Android para Programadores: Uma abordagem baseada em aplicativos, Bookman.
Fielding, R., UC Irvine, J. Gettys, J. Mogul, H. Frystyk, L. Masinter, P. Leach e T.
Berners-Lee (1999), ‘ Hypertext Transfer Protocol – HTTP/1.1’. Tornou obsoleta a
RFC 2068.
URL: https://tools.ietf.org/html/rfc2616
Frankel, S. e S. Krishnan (2001), ‘IP Security (IPsec) and Internet Key Exchange (IKE)
Document Roadmap’. Tornou obsoleta a RFC 2411.
Gomes, Daniel Adorno (2010), Web Services SOAP em Java: Guia Prático para o desenvolvimento de web services em Java, Novatec.
(Citado nas páginas 16, 17, e 26)
56
Index, Global Web (2014), ‘Two thirds of mobile audience using Android’. Junho 2014.
URL: http://www.globalwebindex.net/blog/android-os
J. Arkko, Ericsson, C. Pignataro (2009), ‘Address resolution protocol’. Atualizada pelas
RFC: 826, 951, 1044, 1329, 2131, 2132, 2176, 2225, 2834, 2835, 3315, 4338, 4361, 4701.
Kurose, Jim e Keith Ross (2013), Redes de Computadores e a Internet: uma abordagem
top-down, Pearson.
(Citado nas páginas 2, 7, 8, 9, 10, 11, e 13)
Lennon, Joe (2011), ‘Explore o MongoDB’. Julho 2011.
URL: http://http://www.ibm.com/developerworks/br/library/os-mongodb4/
Li, Yishan e Sathiamoorthy Manoharam (2013), ‘A performance comparison of SQL and
NoSQL databases’, 2013 IEEE Pacific Rim Conference on p. 5.
Lopez, Pablo, David Fernandez, Jose F. Castillo, Miguel A. Zamora e Antonio F. Skarmeta
(2013), ‘Mobile Digcovery: A Global Service Discovery for the Internet of Things’,
27th International Conference on Advanced Information Networking and Applications
Workshops p. 6.
Lyon, Gordon “Fyodor” (2012), Exames de Rede com NMAP, Ciência Moderna.
Medeiros, Joao P. Souza (2014), A Influência da Observabilidade e da Visualizacão Radial
no Projeto de Sistemas de Monitoramento de Redes de Computadores, Doutorado,
Universidade Federal do Rio Grande do Norte - UFRN.
Medeiros, Joao P. Souza, Paulo S. Motta Pires, Joao B. Borges Neto e Antonio A. F.
Loureiro (2015), ‘Minimization and Placement of Sensors in Structurally Observable
Networks’, The 15th IEEE International Conference on Computer and Information
Technology (CIT 2015) p. 8.
Medeiros, João Paulo Souza (2009), Identificação remota de sistemas operacionais utilizando análise de processos aleatórios e edes neurais artificiais, Dissertação de mestrado,
Universidade Federal do Rio Grande do Norte.
Medeiros, João Paulo Souza e Selan R. Santos (2009), RadialNet: An Interactive Network
Topology Visualization Tool with Visual Auditing Support, em ‘Critical Information
Infrastructure Security’, Springer Berlin Heidelberg, pp. 168–179.
57
Mednieks, Zigurd, Laird Dornin, G. Blake Meike e Masumi Nakamura (2012), Programando o Android, Novatec.
Mockapetris, P. (1987), ‘Domain names - implementation and specification’. Tornou obsoleta as RFC 882, 883 e 973.
MongoDB (2015), ‘NOSQL Database Explained’.
URL: https://www.mongodb.com/nosql-explained
Moy, J. (1998), ‘Open shortest path first’. Tornou obsoleta a RFC 2178.
Nakamura, Emilio Tissato e Paulo Lı́cio de Geus (2007), Segurança de redes em ambientes
cooperativos, Campus.
Ogliari, Ricardo Silva e Robison Cris Brito (2014), Android: Do Básico ao Avançado,
Ciência Moderna.
Peres, André, César Augusto Hass Loureiro e Marcelo Augusto Rauh Schmitt (2014),
Redes de Computadores II: Nı́veis de transporte e rede, Bookman.
Postel, J. (1981a), ‘Internet Control Message Protocol’. Atualizada pelas RFC: 777, 760.
Postel, J. (1981b), ‘Transmission Control protocol’. Atualizada pelas RFC: 1122, 3168,
6093, 6528.
Postel, J. (1981c), ‘User Datagram Protocol’. Atualizada pelas RFC: 1122, 3168, 6093,
6528.
Postel, J. e J. Reynolds (1983), ‘Telnet protocol specification’.
Postel, Jon (1998), ‘Routing information protocol’. Tornou obsoleta as RFC 1723 e 1388.
58
R. Droms, Bucknell University (1997), ‘Dynamic host configuration protocol’. Tornou
obsoleta a RFC 1541.
Rekhter, Y., T. Li e S. Hares (2006), ‘A border gateway protocol 4 (bgp-4)’. Tornou
obsoleta a RFC 1771.
Rogers, Rick, John Lombardo, Zigurd Mednieks e Blake Meike (2009), Android: Desenvolvimento de Aplicações Android, O’REILLY Novatec.
Tanenbaum, Andrew S. (2003), Redes de Computadores, Novatec.
(Citado nas páginas 3, 7, 10, e 19)
Wei, Qiang e Zhi Jin (2012), ‘Mobile Digcovery: A Global Service Discovery for the
Internet of Things’, Internetware ’12 Proceedings of the Fourth Asia-Pacific Symposium
on Internetware p. 6.

- LabEPI

Transcrição

Documentos relacionados

Confira como instalar e usar o Flash Player no seu equipamento

Bolo do Caco Bimby: 27 min Ingredientes: 1 c. café sal

Aplicativo Habbo para Android é lançado na Play

Fettuccine à Alfredo Ingredientes: 400 g massa fettuccine ou

Lenovo adquire CCE em busca da liderança no

COMUNICADO DE IMPRENSA flaregames anuncia a data de

Apresentação Engº Mário Fernandes - Siteinforma

universidade tecnol´ogica federal do paran´a departamento

Expandindo uma Arquitetura para HPC em Nuvens

Empanada de Frango com Sultanas Ingredientes p/ a massa