quarta-feira, 3 de dezembro de 2014

Protegendo o dados de banco definido como resource do tomcat

Boa noite negada.

Tem muito tempo que estou devendo esse artigo pois é extremamente importante
do ponto de vista de segurança. Só que ando um pouco sem tempo.

As aplicações que fazemos deploy no tomcat normalmente fazem acesso ao banco de dados
e as configurações para esse acesso sempre ficam expostas em um arquivo XML.
Se um invasor conseguir acesso ao nosso ambiente de produção, é só abrir o arquivo context.xml
no diretório conf do tomcat e todos os usuários e senhas estarão lá.

Então, uma ótima forma de dificultar esse acesso é criptografando a senha.
Sempre dizem que encriptar a senha é mover o problema para outro lugar.
Concordo plenamente. Então vamos mover para um lugar que exija conhecimento do cracker
para descobrir qual jar está nossa factory, decompilá-lo, executar o projeto e
alterar o código para desencriptar. Com quase nada, vamos dificultar bastante a vida de um atacante.



Esse arquivo é do meu tomcat e mostra 3 resources (apaguei os passwords do screenshot). Cada um é de uma aplicação e os três fazem acesso ao banco de dados local. Note que o type está definido como javax.sql.DataSource.
O que iremos fazer é adicionar uma factory que receba todos esses parametros, decifre a senha
e coloque a senha decifrada antes de abrirmos a conexão com o banco.

Vamos então criar a nossa factory...



Reparem que a única coisa que ela faz é pegar o object, converter em BasicDataSource,
pegar a senha, decifrar e setar a senha decifrada no objeto. Simples assim!

Agora a gente se encontra com outro problema: como cifrar e decifrar a senha ?
Isso vai vai de cada um mas vou colocar o código que usei. Estou usando criptografia
com o AES com chave de 256 bits (o algoritmo aceita chaves de 128, 192 e 256 bits). Deixei o exemplo usando o algoritmo DES também mas não é recomendado utilizá-lo pois sua segurança já foi quebrada.
Note que quando vamos decifrar a senha usando o algoritmo AES, é adicionado um IvParameterSpec
que foi criado com um array de bytes. Isso acontece porque o AES é um algoritmo cifrado de bloco.
Voce pode mudar o conteúdo do array para o que voce quiser, desde que o mesmo array seja utilizado
tanto para cifrar quanto para decifrar a senha.



Pronto. Agora basta gerarmos o jar do nosso projeto e adicionar na pasta de libs do tomcat
que fica em $TOMCAT_HOME$\lib.
Para fazer o encode e decode em Base64, eu usei o apache commons-codec. Então esse jar tambem
deve ser adicionado à pasta do tomcat para funcionar corretamente. Caso voce não queira o commons-codec como uma dependência e quer fazer funcionar apenas com nossa classe (nosso jar), basta fazer o encode e decode da Base64 na mão. Assim, nao é necessário o commons-codec.

Importante: assim como criptografamos a senha no arquivo context.xml, podemos criptografar todos os outros dados como usuário e url de conexão.

Referência: http://stackoverflow.com/questions/129160/how-to-avoid-storing-passwords-in-the-clear-for-tomcats-server-xml-resource-def


sexta-feira, 29 de agosto de 2014

Segurança: Se protegendo contra um Shell Reverso

Um dos ataques mais perigosos é quando uma vulnerabilidade permite o atacante abrir um shell-reverso. Com isso o atacante ganha acesso à máquina invadida e consegue executar comandos no shell (terminal, prompt). A técnica é chamada de shell-reverso pois o atacante faz com que a máquina-alvo abra uma conexão para sua máquina. Logo, o firewall (que normalmente é configurado para barrar conexões de entrada em portas "desconhecidas") não consegue impedir a conexão.

Primeiramente vamos entender o conceito de firewall de host. O objetivo dele é aplicar regras para impedir ou bloquear conexões de serem estabelecidas com a máquina em que ele está instalado. Por padrão, o firewall do WINDOWS bloqueia as conexões de entrada que não estiverem liberadas por nenhuma regra e libera as conexões de saída que não casarem com nenhuma regra. Ou seja, conexões de entrada são bloqueadas e de saída (onde se encaixa o shell-reverso) são liberadas.



OBS.:

  • Conexões de entrada: conexões chegando na máquina onde o firewall está instalado
  • Conexões de saída: conexões saindo da máquina onde o firewall está instalado


Vamos supor que temos um servidor windows com um IIS rodando disponibilizando um portal web. Quando um cliente acessa o endereço desse servidor, é estabelecida uma conexão na porta 80 com o servidor. Ocorre o three-way handshake, a conexão é estabelecida e o servidor escreve o index do portal web para o cliente. A conexão então é fechada. E vamos supor que exista uma falha no nosso servidor que possibilite esse tipo de ataque.

Então como impedir essa conexão do shell-reverso de ser estabelecida ? É simples. Basta barrar todas as conexões de saída da máquina (Teoricamente, nosso servidor não faz requisições em nenhum lugar. Ele só atende requisições na porta 80). Para isso, basta ir no Painel de Controles, acessar a parte de Segurança e então o Firewall. Clicar na opção avançada do firewall. Irá abrir a tela com as regras de entrada e saída para o firewall.


Ao clicar com o botão direito em cima de "Windows Firewall with Advanced Security on Local Computer" (nú! que nome foi esse ?) e acessar propriedades, aparecerá a tela acima na qual está definida as regras padrão para conexões de entrada e de saída. Basta mudarmos Outbound connections para Block. Agora nosso firewall irá bloquear todas conexões de entrada que não casarem com alguma regra de liberação. 

Dessa forma, se sofrermos algum ataque que possibilite o shell-reverso, a conexão será barrada pelo firewall e falhará. Simples assim. Pra quem usa linux como servidor (99%), essas regras são definidas pelo iptables. Depois faço uma publicação explicando. 

Abraço. E qualquer dúvida, ja sabem...


Alias lembrei de uma coisa interessante. Já viu quando você acessa uma rede wireless e o windows te pergunta se é uma rede residencial, de trabalho ou pública ? Já parou pra pensar porque aquela tela chata sempre aparece ? É justamente para uma configuração automática do firewall. Quando você diz que é uma rede residencial (rede da sua casa), o windows entende que há pouca chance de ocorrer um ataque e configura o firewall para ser mais maleável. Quando você diz que está acessando uma rede pública (Wifi Grátis), o windows entende que há uma maior chance de ocorrer um ataque à sua máquina e configura o firewall com mais regras para tentar barrar ataques. E pensar que a maioria da galera clica sempre em rede residencial e deixa o firewall sem barrar quase nada heim ??? Te falar...

domingo, 20 de julho de 2014

Segurança: como configurar o tomcat

Boa noite a todos.

Hoje vou escrever sobre um assunto extremamente importante quando vamos fazer um deploy de uma aplicação na internet usando tomcat. O motivo desse post é porque eu migrei recentemente do kinghost para o digitalocean. No kinghost, você recebe um tomcat já preparado contra essa vulnerabilidade. Mas no digitalocean, como você "aluga" uma máquina, você mesmo tem que tomar esses cuidados.

Primeiramente, vou explicar como funciona essa vulnerabilidade do tomcat (na verdade não pode nem ser considerado uma vulnerabilidade pois não há falhas. O que há é falta de configuração).

Vamos supor que você baixe o tomcat do site da apache, descomente os usuários e permissões no arquivo tomcat-users.xml para ter acesso à àrea de administração (deploy de aplicativos) e coloque ele pra rodar no seu servidor. Já lascou tudo! A sua área de administração (manager) está exposta. Mas vamos desde o início... Vamos subir o tomcat sem nenhum projeto para deploy. Quando você acessar http://localhost:8080, você vai ver o index do tomcat como na imagem abaixo:


Note que no canto esquerdo tem um quadro de administração. E o segundo link é Tomcat Manager.
Essa é a área de administração que eu estava falando. Quando você clicar nesse link, ele pede usuário e senha para entrar. Essas credenciais devem ser definidas no arquivo $TOMCAT_HOME/conf/tomcat-users.xml.



Caso você esteja se perguntando qual o problema disso, vou explicar:
O atacante dentro da página de gerenciamento com credenciais de administrador, pode tirar nossa aplicação no ar. Pior que isso: ele pode adicionar uma aplicação no nosso tomcat. E essa aplicação normalmente adicionada pelo atacante, abre um shell reverso(*) que possibilita acesso ao seu servidor. Resumindo, se um atacante entrar nessa área e fazer deploy dessa aplicação, ele pode ter acesso a todos os dados do seu servidor.

Agora vamos considerar o seguinte: normalmente, as pessoas utilizam sistemas Linux como servidor. E em um sistema unix-base, você só sobe seu servidor na porta 80 se for root. O que um usuário normal faz ? Acessa o usuário root e sobe o servidor na porta 80. Quando o atacante fizer o deploy, ele vai acessar o shell com permissão do usuário que iniciou o processo, ou seja, o root!

Acho que agora já deu pra entender a gravidade da situação né ? É tenso mesmo.
Vejamos agora as formas de acabar com isso:

1) Alterando as senhas e usuários padrões (o mais lógico a se fazer)

Para isso, basta que modifique o arquivo $TOMCAT_HOME/conf/tomcat-users.xml alterando os valores padrões e colocando senhas fortes.

2) Remover a área administrativa (modo ignorante)

Nesse ponto é importante saber que a área administrativa é uma aplicação java normal como qualquer outra. E se a vulnerabilidade está nela, então basta deletá-la que a vulnerabilidade irá sumir (quanto menos código, menos bug e menos vulnerabilidade).
Para isso, basta ir na pasta $TOMCAT_HOME/webapps e deletar as pastas docs, examples, host-manager e manager. São todos aplicações do tomcat e não precisamos de nenhuma delas. Delete essas mesmas pastas dentro de $TOMCAT_HOME/work/Catalina/localhost

3) Remover a área administrativa e alterar permissões de pasta (modo ignorante nível hard)

Essa terceira opção, além de remover os aplicativos que não precisamos, funciona como uma prevenção contra outras possíveis vulnerabilidades que o tomcat possua e que ainda não foram descobertas. Não é necessário fazer esse passo pois ele é apenas preventivo.
A lógica desse ataque, é que o atacante utiliza o próprio tomcat para escrever um projeto dentro do servidor. A partir daí, ele faz o que quiser... Mas e se o tomcat não puder escrever na pasta webapps ??? Parece meio estranho mas funciona. Basta você tirar as permissões de escrita na pasta $TOMCAT_HOME/webapps após subir o tomcat. Assim, quando o atacante tentar fazer deploy na pasta, ele não vai ter permissão para escrita e não irá funcionar.


Exemplos:

Eu resolvi fazer esse post porque em 1 dia que coloquei meu tomcat desconfigurado no digitalocean, sofri 2 ataques desse tipo. Eu acho que tinha deixado usuário e senha como "admin" (vacilão). E detalhe: só fiquei sabendo porque o atacante começou a levar tudo do meu servidor e o digitalocean percebendo o grande fluxo de upload, bloqueou meu droplet.


Essa primeira imagem está o index do primeiro ataque. Olhei pouco o código mas vi que serve pra roubar dados do servidor e mandar pra um server remoto.


Nessa segunda imagem, foi o segundo ataque



Criei esse post aqui para mostrar outra forma de barrar um shell reverso.


quarta-feira, 2 de julho de 2014

Realizando acesso externo a um servidor JBoss

Ontem meu grande brother Miller precisou de uma mão nesse ponto e então surgiu a idéia de fazer esse post. Hoje vou falar sobre como acessar externamente diferentes versões do JBoss.

Primeiramente, vamos situar o problema. Voce é desenvolvedor e utiliza o JBoss para testar seu projeto na sua própria máquina. Até aí tudo bem. Tudo funciona. No entanto, no momento de por o projeto em homologação do cliente ou então em produção, voce não consegue mais acessar o servidor. Porque ?
É simples. O JBoss vem configurado apenas para acessos locais (da própria máquina que está instalado). Quando o acesso vem da rede, ele é negado.

Como corrigir isso ?

JBoss 4.X e 5.X

Para esses JBoss, sendo os mais famosos as versões 4.2.3 e 5.0.1, temos a mesma forma de liberar acesso externo. Basta adicionarmos o comando -b 0.0.0.0 !! Isso por si só já libera acessos da rede ao JBoss. Mas onde colocarmos esse comando ?? Aqui dividimos em duas partes:

  1. Iniciar JBoss pelo Eclipse

    Existem várias formas de iniciar o servidor pelo eclipse. A primeira é pela view de Server
    No entanto dessa forma, não nos permite mexer na configuração do JBoss.



    Então nós iremos pelo botão de RUN do eclipse que é esse verde do meio na imagem abaixo.



    Tudo que é iniciado pelo eclipse (seja servidor, programa java standalone ou programa android) fica no histórico. E ao clicar na setinha para baixo ao lado do botao de RUN, temos o histórico e a opção Run Configurations que é onde iremos clicar.


    Quando abrimos essa tela de configuração de execução, será mostrado as configurações do ultimo RUN executado (que no meu caso é do servidor).



    Repare que na tela à esquerda, abaixo de Generic Server temos a configuração do JBoss v4.2 at localhost que é o que quero alterar.
    Ao abrir na tela direita as configurações de startup do servidor, clica na aba Arguments para colocar nossa opção -b 0.0.0.0 como Program Argument de execução do servidor. Agora basta clicar em Apply e Run. Pronto! Seu servidor estará acessível de outras máquinas.

    OBS.: Execute o mesmo procedimento para DEBUG
  2. Iniciar JBoss por linha de comando

    Quando o startup do JBoss é feito apenas por linha de comando (que é o caso de servidores sem interface gráfica - até porque ninguém abre o eclipse dentro de um servidor pra iniciar o JBoss), temos que passar esse argumento na linha de comando. Isso pode ser feito de dois jeitos.
    1. bash run.sh --host 0.0.0.0

      Para subir o jboss é necessário entrar no diretório de instalação do JBoss, acessar a pasta bin e executar o arquivo run.sh. Se voce estiver em um windows, deve executar run.bat. Agora basta passar como argumento --host 0.0.0.0 e pronto! Todo mundo por acessar seu JBoss.
    2. bash run.sh -Djboss.bind.address=0.0.0.0

      É o mesmo que a opção 1 mas dito de outro jeito. Ambas funcionam

JBoss 7.X e 8.0.1 (Wildfly)

Para o JBoss 7 e 8, cujo versões mais famosas é a 7.1.1 e 8.1.0, muda um pouco a forma de fazer essa configuração. Isso porque o servidor foi reestruturado com a idéia de domínios (assim como o glassfish já fazia). 
Agora temos a opção de subirmos domínios do JBoss ou também subir standalone (que é a forma como as versões antigas faziam).

Para essa versão do JBoss, vamos realizar o acesso pelo JBoss standalone. Para isso vamos acessar o arquivo standalone.xml que fica em $JBOSS_HOME/standalone/configuration.standalone.xml e busca pela palavra inet . Basta colocar o "famoso" 0.0.0.0 nesse endereços.



A imagem acima mostra que coloquei em todos. No entanto só é necessário e recomendado, colocar o 0.0.0.0 na interface com nome public. Não é necessário colocar em todos como foi feito na imagem acima.

Lembre-se... Se voce estiver em ambiente corporativo, pode ser necessário criar regra em firewall para liberar acesso.
Qualquer dúvida que voce tiver, posta aí que vou dar um jeito.

Abraço!!!


segunda-feira, 30 de junho de 2014

Definindo a URL do seu site

Bom dia geral.

No último post, eu mostrei como construir um servidor de aplicações barato para hospedar suas aplicações e sistemas (caso voce não tenha visto, dê pelo menos uma lida rápida aqui para ajudar no entendimento). No entanto, o acesso SSH é feito através do endereço IP que o digitalocean disponibiliza para nós. Quando eu fiz a hospedagem no kinghost, esse gerenciamento da URL do site é todo feito por eles. Mas como optamos por fazer na mão todas essas configurações, ficou faltando esse ponto.

Primeiramente, temos que comprar a URL. Ela precisa estar disponível. Existe vários sites que fazer esse serviço de venda de URL, como o http://registro.br/ e o http://godaddy.com. No meu caso, vou usar o godaddy.com e tentar registrar o domínio http://voudarumjeito.com.br


Olha que beleza. Está disponível. Só tenho que criar uma conta no site e comprar o domínio por 30 reais no ano e pronto. Essa url http://voudarumjeito.com.br será minha. No entanto, quando alguém acessar essa url, não vai ter nada pois ainda tenho que fazer o redirecionamento para meu servidor do digital ocean (vou até desenhar isso pra ficar fácil entender).


A lógica é a seguinte


  1. O usuário acessa pelo celular a url http://voudarumjeito.com.br
  2. A requisição chega no godaddy e ele redireciona para nosso servidor no digitalocean
  3. O nosso servidor atende à requisição retornando a resposta
  4. O godaddy retorna para o celular o que o servidor no digitalocean retornou
Simples assim! No entanto, o passo 2 e 3 ainda não existe. Quando a requisição chega no godaddy, ele não sabe que deve redirecionar para nosso servidor no digitalocean. Então vamos fazer esse passo funcionar!

Acesse o godaddy com usuário e senha que voce criou para criar o domínio. Então acesse Domínios, e clique no botão Iniciar.



Na sessão Encaminhamento, clicar em Administrar logo abaixo de Domínio e criar seu encaminhamento para seu ip no digitalocean. Simples assim.
Agora temos a url que aponta para nosso servidor e tudo funciona perfeitamente.
Se tiver dúvida em relação à esse direcionamento, aqui tem um manual de ajuda do godaddy. Ou então é só postar aí nos comentários que vou dar um jeito. 

Abrassss

quinta-feira, 26 de junho de 2014

Criando um servidor do seu jeito... e barato!

Aooo moçada.

Como tinha muito tempo que não aparecia por aqui resolvi fazer dois posts hoje. E de longe, esse aqui é disparado o mais interessante até hoje.
Mesmo postando sempre assuntos relacionados à redes, eu sou desenvolvedor de origem. Vi necessidade de estudar redes pois no curso de ciência da computação aprendemos muito pouco nesse assunto. Eu sempre ficava com dúvidas de como colocar minha aplicação na internet. Um das formas (e a que não possui custo) é utilizando DDNS que expliquei nesse tópico. A outra forma é registrar um domínio e hospedar em um servidor na internet. E é disso que vamos falar.

Atualmente possuo uma conta no kinghost. Nada a reclamar. Inclusive é o melhor serviço de hospedagem que já contratei no Brasil (e único.. hehehehe). Ele te provê várias ferramentas previamente instaladas como

  • Subversion
  • Tomcat (servidor java)
  • MySQL, Firebird, Postgres, Oracle
  • Mais uma cacetada de coisa (não vou ficar falando porque eles não me pagam pra isso. Quem quiser dá uma olhada lá).
No entanto, eu fazia pagamento de 124 reais trimestrais. Isso dá uns 42 reais por mês e queria algo mais barato. E foi aí que o Geléia me apresentou o digitalocean. Vou mostrar passo a passo como fazer uma hospedagem no site.

O primeiro a se fazer é uma conta no site. Assim que entrar no digitalocean, já tem a opção de adicionar email e senha e criar uma conta. Simples assim. Voce será direcionado para a tela inicial onde existe o seguinte fluxo:



  1. Update Billing (Cadastro da forma de pagamento): coloque o seu cartão de crédito. Pode colocar sem medo. Ele ficará cadastrado e só será cobrado de acordo com o perfil (numero de CPU's, memória, etc) que voce escolher. Vale lembrar que a cobrança é em dólar.
  2. Create Droplet: O site se chama oceano digital. E as gotas desse oceano são os servidores. Então quando voce ver droplet, significa servidor. É aqui que voce irá criar a sua máquina e é também o o ponto mais impressionante desse serviço.
  3. Root Access: Depois que voce criar seu droplet (servidor), voce receberá a senha do root por email. E aí já pode fazer acesso via SSH.
OBS.: Caso tenha algum novado em linux lendo esse tutorial, ja adianto que todo o acesso ao seu droplet é por linha de comando. Logo, caso tenha dificuldades, estude linux primeiro ou então me pergunte ao final deste post.

Criando um Droplet

Chegamos ao que realmente interessa. A criação no nosso servidor.
Primeiramente, não possui windows pois windows é pago e precisa de licença. Então teremos apenas distribuições linux.
As configurações de máquina variam da quantidade de CPU's, a capacidade de armazenamento do disco rígido, a quantidade de memória e o tráfego de rede. Tem configuração pra tudo que é gosto.
  • Pior configuração: 512 MB de RAM, 1 CPU, 20 GB de SSD e 1 TB de transferência
  • Melhor configuração: 64 GB de RAM, 20 CPU's, 640 Gb de SSD e 9TB de transferência
A configuração da sua máquina depende muito do que voce vai fazer. Como eu precisava de um servidor para aplicação Java, escolhi a segunda máquina com 1 CPU e 1 GB de memória RAM.


Depois de escolher a configuração de máquina, há a opção de escolher até a localidade da máquina. As opções são apenas Nova Iorque, Amsterdam, São Francisco e Singapura. 

Após isso, é hora de selecionar a distribuição linux desejada. As opções são:
  • Ubuntu (versão 10.04 até a 14.04)
  • Fedora (versões 19 e 20 com 32 e 64 bits)
  • Debian (versões 6 e 7 com 32 e 64 bits)
  • CentOS (versão 5.8 até a 6.5)
  • Arch Linux (está sendo descontinuado pelo digitalocean. Melhor não usar)


Como o acesso é feito por SSH, é necessário criar uma chave privada na sua máquina e adicioná-la ao servidor. Quem não tem nem ideia do que estou falando, acesse esse link, crie sua chave, e depois adicione à sua conta. E por fim, é só clicar para criar seu droplet. Simples assim.

OBS.: ao final, antes de clicar para criar o droplet, há a opção de backup. Essa opção custa um pouco mais caro mas é uma segurança de que voce possui backup da máquina inteira caso aconteça alguma cagada.

Com o acesso SSH funcionando, voce possui uma máquina só sua. Inclusive cuidado ao usar o usuário root e ferrar com a máquina toda (sim, isso é possível). Agora basta copiar um servidor para lá e iniciá-lo. Outro fato importante é se atentar a ataques. Quando coloquei meu tomcat (servidor java) no meu droplet e iniciei, sofri 2 ataques em dois dias. Mas eu também deixei ele prontinho pra sofrer ataque. Depois faço um post mostrando como foi o ataque, como fazê-lo e como se defender desse ataque.

Outra coisa importante. O digitalocean te dá apenas um IP público estático para voce fazer a conexão. Então voce terá que fazer acesso como ssh@163.244.123.32. Ou entao para acessar seu servidor, deverá digital no navegador http://163.244.123.32
Caso voce tenha interesse em ter um nome que represente esse domínio (exemplo: http://voudarumjeito.com.br), criei um tutorial de como fazer aqui.

Qualquer problema com seu droplet, posta a dúvida aí embaixo que eu dou um jeito! :P



terça-feira, 10 de junho de 2014

Instalação de servidor FTP

Boa noite.

Esse tópico sai um pouco da área de redes mas tem tudo a ver com os tópicos da camera ip. Isso porque a nossa camera possui uma funcionalidade muito interessante que é de enviar fotos para um servidor FTP quando detecta movimento. Então para podermos tirar o máximo proveito das suas funcionalidades, vamos realizar a instalação de um servidor FTP.

No meu caso, usarei um servidor linux Ubuntu 12.04.
O procedimento é extremamente simples (nem sei se precisava desse tutorial).

O servidor a ser instalado será o vsftpd.
Primeiro passo, é utilizar o apt-get para realizar a instalação:
Como root, realizar o comando apt-get install vsftpd


Caso voce seja completamente iniciante em linux e não tenha entendido a parte do apt-get, deve ser porque voce está usando uma interface gráfica (com janelas, imagens parecido com o windows). Nesse caso, você precisa ir para um terminal de comandos. Segure as teclas CTRL + ALT e aperte a letra T. Isso abrirá um terminal e voce poderá executar o comando na imagem.

O apt-get é um programa utilizado para instalar outros programas ou bibliotecas. Ele consulta um repositório e exibe as opções de sistemas disponíveis para instalação. Após a execução do apt-get, o vsftpd é instalado e já colocado em execução. Para garantir que o servidor está funcionando, execute o comando ps aux | grep vsftpd . Deverá aparecer a seguinte linha como na imagem abaixo:


Com o servidor funcionando, já podemos realizar conexão. Vou utilizar o cliente FTP chamado Filezilla. Nesse momento é importante lembrar que é necessário se autenticar para acessar os arquivos do servidor. Usaremos o usuário anonymous (usuário padrão do servidor FTP) que não possui senha.


No primeiro frame do programa, mostra o log da conexão. Podemos ver as seguintes linhas:

  • USER anonymous
  • PASS **************
  • 230 Login successfully
Ou seja, conseguimos autenticar com o usuário anonymous. No segundo frame do Filezilla, vemos o Local site (minha maquina) e Remote site (servidor FTP). No entanto, não aparece nenhum arquivo no Remote site. Isso acontece pois o usuário anonymous não possui permissão de visualização de nenhum arquivo e não pertence a nenhum grupo de usuários do linux. Logo, o melhor a ser fazer é utilizar os usuário e senha do linux para efetuar login no servidor FTP também. Para isso teremos que modificar o arquivo /etc/vsftpd.conf


OBS.: É extremamente recomendável comentar a linha anonymous_enable=YES para que usuários anonymous não consigam se autenticar.

Nesse ponto o que precisa ser feito é descomentar as seguintes linhas:
  • local_enable=YES
  • write_enable=YES
Para descomentar basta retirar o caracter # do início da linha.
Como o servidor estava funcionando, ele precisa ser reiniciado para ler o arquivo de configuração novamente e aceitar autenticação com os usuários do sistema.
Como ele foi instalado como serviço, utilizamos o comando service do linux para chamar um serviço.
  • service vsftpd restart
Agora conseguimos autenticar com os usuários cadastrados no linux.



Observações:
  • service vsftpd stop (parar o serviço do vsftpd)
  • service vsftpd start (parar o serviço do vsftpd)
  • service vsftpd restart (reiniciar o serviço do vsftpd)

Para maiores dúvidas sobre a instalação, click aqui
Caso voce queira instalar um servidor FTP no Windows, existe o servidor de FTP do Filezilla aqui. Atente-se para realizar o download do arquivo que é servidor FTP e não cliente FTP.

Qualquer dúvida, posta aí nos comentários que vou dar um jeito.
Abraço.

quinta-feira, 8 de maio de 2014

NAT - Network Address Translation

Boa noite negada.

Vou fazer esse tópico para complementar o tópico de port-forwarding. É uma explicação mais a grosso modo (sem entrar em detalhes) mas pode ser lido separadamente para entendimento do NAT.

Vamos falar primeiramente sobre as camadas e os protocolos nessas camadas.

Vamos olhar as camadas de interface de rede. A que mais conhecemos é a ethernet, sobre a qual utilizamos para o uso da internet. No entanto, a internet (navegação em páginas) funciona através do protocolo HTTP que está na camada de aplicativos. Logo, existe uma hierarquia entre as camadas. Para acessarmos uma página na internet, utilizamos a sequência HTTP, TCP, IP, Ethernet.

Toda a nossa internet é baseada em cima da camada de internet IP. Ou seja, para que uma máquina se conecte na internet é necessário adquirir um IP de uma rede. Um IP é uma sequência ÚNICA de quatro conjuntos de números com no maximo 3 números cada. Exemplo: 187.124.243.211. Uma observação importante. Cada um desses conjuntos não pode ser maior que 255.

Pensando assim, podemos ver que existe um número fixo de IP's disponíveis (4 294 967 296 IP's). No entanto, se considerarmos todos os dispositivos conectados a internet, veremos que existe uma quantidade muito maior que os 4 bilhoes de IP's disponíveis (O dado revelado pela pesquisa “The Cisco Visual Networking Index Global Mobile Data Traffic Forecast Update" estima que o número de dispositivos conectados vai ultrapassar a população mundial em 2010, e que em quatro anos, chegará a casa dos 10 bilhões). Como é possível 10 bilhões de dispositivos se conectarem à internet se possuímos apenas um pouco mais de 4 bilhões de endereços IP's ? É possível justamente por causa do NAT. O NAT é uma forma utilizada para economizarmos os endereços IP's da internet.

Vou dar o exemplo da internet da minha casa. Atualmente, tem 6 smartphones, 4 notebooks, 1 Câmera IP  e uma Smart TV(sim, tem muita gente aqui). Como todos se conectam à internet, precisamos reservar 11 IP's dos 4 bilhões disponíveis, certo ? Não. Para todos esses dispositivos, temos apenas 1 endereço IP reservado na internet do mundo. E esse único IP pertence ao modem. Todos esses aparelhos estão abaixo do modem e não possuem acesso direto à internet. A internet do mundo conhece apenas nosso modem. Vamos simular um acesso ao site do google.

Eu abro o browser no meu celular que tem o IP de rede 192.168.0.103, e digito www.google.com.br. A requisição sai do meu celular, e vai para o roteador. O roteador registra que aquela requisição é da máquina com IP 192.168.0.103 e envia para o modem. O modem envia a requisição para a internet e a resposta chega a ele. Como ele só conhece o roteador na rede interna, ele repassa para o roteador. Já o roteador, conhece vários dispositivos. Ele pega a resposta, vê que a requisição foi feita pela máquina de endereço IP 192.168.0.103 e encaminha a resposta para essa máquina. Eu então visualizo o site do google no meu celular. Essa "jogada" que o roteador faz de guardar o endereço da máquina para depois lhe entregar a resposta, é chamado de NAT e permite que os smartphones e notebooks daqui de casa possa acessar a internet sem ter um IP válido.

Vale a pena lembrar. Os dispositivos na minha rede interna (smartphone, tv, camera e etc) possuem um IP. No entanto, esses IP's são chamados de IP's não válidos pois não são visíveis da internet. Já o roteador é o único que possui um IP válido pois é acessado de qualquer lugar da internet.

OBS.: Qualquer IP que possua um conjuto de valores maior que 255 é considerado inválido (Exemplo: 183.370.221.111 - Note que 370 não é um conjunto válido por passar de 255).

OBS. 2: Atualmente utilizamos a versão 4 do protocolo IP, chamado de IPv4. Realmente os endereços IP's válidos estão se esgotando na versão 4. No entanto já existe uma solução de contorno a muito tempo e é a versão 6 no protocolo IP (conhecido como IPv6). No IPv6 há uma mudança brusca em como será os IP's e as principais empresas do mundo (Google, Facebook, Yahoo, Cisco) realizam um dia anual para testes do IPv6.

Referências:
http://pt.wikipedia.org/wiki/Exaust%C3%A3o_do_IPv4
http://www.cisco.com/c/en/us/solutions/collateral/service-provider/visual-networking-index-vni/white_paper_c11-520862.html
http://pt.wikipedia.org/wiki/IPv6
.

segunda-feira, 5 de maio de 2014

Port-Forwarding e DDNS: Acessando sua IP-Camera de qualquer lugar

Acabei de encontrar esse tópico aqui como rascunho no blog... Já era pra tê-lo feito a muito tempo pois é parte importantíssima para a camera-ip (ou qualquer dispositivo de rede que você quiser) funcionar com sucesso. Já criei alguns tópicos nos quais fui circundando os tópicos necessários para configurar e por pra funcionar uma camera-ip na nossa rede... Foram assuntos de redes, roteador, até chegar nas configurações da câmera propriamente dita. Então vamos lá:

Após a alegria da câmera-ip funcionar na nossa rede e conseguirmos ver sua imagem, falta conseguirmos enxergar essa imagem de qualquer lugar do mundo. Ou seja: você quer ver o que está acontecendo na sua casa do computador do seu trabalho ? Pode! Você quer ver do seu celular ? Pode tambem! Vamos dar um jeito nisso.

Primeiramente vamos entender os passos que devem ser feitos:
1) Conseguir driblar a dinamicidade do nosso IP
2) Configurar regras do nosso roteador e camera (Port-Forwarding)
3) Configurar câmera-ip com IP estático na nossa rede
4) Acessar dispositivo

Vamos às explicações de cada um dos tópicos:
1) A maioria das redes domésticas, é um cabo RJ-21 (de telefone) que se conecta em um modem e um roteador que se conecta ao modem através de um cabo RJ-45 (de rede). A partir daí, o roteador distribui o sinal WI-FI e os dispositivos se conectam ao roteador. O primeiro problema é justamente com o modem pois ele é o único dispositivo que é visível na internet (isso aqui tá ficando complicado. Então vou fazer um outro tópico explicando a visibilidade dos dispositivos na internet. Topico feito aqui). Ele se conecta à rede mundial (internet) e pega um IP válido. Com esse IP, conseguimos atingir nosso modem de qualquer lugar do mundo. No entanto, esse IP é dinâmico. Isso quer dizer que ele muda de tempos em tempos (normalmente quando o modem é desligado).

 Cabo RJ-21 (Cabo do telefone)









                                                                     Cabo RJ-45
                       (Cabo de rede - par trançado)




Como descobrir nosso IP na rede mundial ? Vamos acessar o site http://www.whatismyip.com/ .
Esse site nos dá uma visão muito boa de nosso modem na rede mundial. Na imagem abaixo, tenho o IP que pegamos (179.104.135.214), nenhum proxy detectado na minha rede, a cidade que estou (Uberlândia), o estado (MG), país (BR) e o ISP (Provedor de Serviço de Internet) a CTBC.
Isso quer dizer que se você acessar esse endereço de IP do seu trabalho, você irá acessar meu modem. Sendo assim, você conseguirá acessar também seu modem.

Agora vamos conhecer um outro site. Esse se chama no-ip (http://no-ip.com). Esse site que irá fazer a mágica para a gente. Nós faremos um cadastro grátis nesse site e escolheremos uma URL disponível. No meu caso, escolhi http://thiagorss.bla.org. Você deve estar se perguntando o que essa URL tem a ver né ? É que ao invés de acessarmos nossa camera-ip pelo IP 179.104.135.214, nós iremos acessar o site http://thiagorss.bla.org. Quando uma requisição acessar essa nossa URL, o site no-ip irá se encarregar de redirecionar a requisição para nosso IP de verdade. Mas se o IP muda toda hora, como o no-ip vai saber para onde redirecionar ? Pois nós vamos usar um programa chamado DUC do no-ip que de 5 em 5 minutos irá contar para o site no-ip qual é o ip do nosso modem. Então tópico 1 resolvido.

2) Agora vamos fazer o chato Port-Forwarding. Isso vai garantir que quando a requisição chegar ao site http://thiagorss.bla.org, o no-ip irá enviar para meu modem, meu modem irá enviar para a requisição para o roteador e o roteador irá enviar para a câmera-ip. No entanto, como demorei 1 ANO pra fazer esse tutorial, trocamos nossa internet por fibra ótica e o aparelho que recebe o cabo de fibra ótica é modem e roteador ao mesmo tempo. Então vou mostrar a configuração nesse aparelho e tiramos duvidas sobre outros aparelhos nas perguntas.


Atualmente os aparelhos tem facilitado bastante o port-forwarding. Na imagem acima, tudo que tive que fazer foi, qualquer requisição que vier na porta 80, redirecione para o IP da minha camera-ip (192.168.0.200) na porta 80 tanto no protocolo TCP quanto UDP. Ative a regra clicando em Enable e salve.

Encontrei essa imagem na internet que explica bem todo o processo:




A requisição vem da internet (celular no 3G, computador da empresa - qualquer computador que náo esteja na rede da sua casa) e o seu provedor de internet (net, ctbc, gvt, etc) redireciona para seu modem. No modem, deve haver uma regra para enviar para o roteador. No roteador, ele redireciona para algum ip da sua rede interna (no nosso caso, o ip da nossa câmera).



Já os itens 3 e 4, me lembrei que já os expliquei aqui. hehehehhe.
Valeu e qualquer dúvida é só postar aí que vou dar um jeito.