IPC 360: Camera IP boa e barata

Boa tarde senhores...

Acabei de encontrar, talvez, a melhor câmera IP que vi nos últimos tempos. E não falo na questão de qualidade ou valor. Mas sim no quesito configuração.

Esse é um dos pontos mais importantes pois já percebi que a maioria das pessoas que me pedem ajuda, não são conhecedoras de assuntos de rede. Por tanto, com certeza é a melhor opção.

Falo isso porque eu fiquei completamente surpreso com a câmera. Ela simplesmente se configurou sozinha. E quanto tive acesso à ela via rede interna, pensei: "agora é ver como é a configuração para a rede externa". Aí quando estava no 4G, fui acessar a camera por curiosidade e pronto: estava tudo funcionando... Sinistro.

Portanto, vamos ao que interessa... Essa é a câmera:

A camera é uma IPC 360. O valor dela na Santa Efigênia foi 250 reais.

Dentro da caixa veio a câmera, o cabo com o plug de energia (igual a de celulares android), o suporte para encaixa e umas buchinhas para perdurar na parede.

A configuração do aparelho chega a assustar do tanto que é fácil.
Primeiro é necessário baixar o aplicativo IPC 360 pelo Google Play.

Agora basta seguinte o passo a passo para configurá-la:
1) Acessar sua rede wi-fi com seu celular
2) Ligar a câmera na tomada. Ela ficará piscando com uma luz vermelha. Caso pisque uma luz verde ao invés de vermelha, significa que ela já foi configurada. Então será necessário resetá-la. Ela possui um orificio na parte traseira para o reset.
3) Se cadastrar através do aplicativo.Você receberá um e-mail para confirmação da conta. Quando receber esse e-mail e confirmar a conta, já estará
4) Adicionar a senha da sua rede wi-fi no aplicativo. Isso é necessário para configurar a câmera.
5) Entrar no aplicativo, e colocar para ele buscar a câmera automaticamente.
6) Com a câmera encontrada, irá pedir um nome para ela.. no meu caso eu coloquei como "Sala" pois ela fica na casa de casa.

A partir daí é só alegria. A câmera está configurada para acesso interno e externo.
Caso você se pergunte como isso é possível, eu explico: ela utiliza streaming para fazer o envio da imagem.
E o resultado é esse:

A imagem tem uma excelente qualidade e possui ângulo de visão de 180 graus. Da pra dar zoom nela sem perder a qualidade. Os botões em baixo são excelentes:

1. O botão de volume à esquerda, possibilita captar o audio do ambiente e é enviado direto para o celular
2. O botão de câmera, bate uma foto da imagem que está sendo transmitida.
3. O botão de microfone no meio é o melhor: permite que você fale e o aúdio é transmitido para a câmera e reproduzido. Então quem estiver no ambiente, ouvirá o que você fala.
4. O botão de vídeo, filma a imagem que está sendo transmitida.

Outra boa funcionalidade é que a câmera possui uma entrada para cartão de memória SD. Basta plugá-lo para que a câmera grave tudo. Apenas lembre-se de sempre desligar a câmera antes de colocar ou remover o cartão para não danificar o aparelho.

Essa é a tela que irá listar todas as câmeras que você possuir cadastradas.

Um dos botões mais praticos é o de compartilhamento. Com ele você consegue permitir o acesso de outras pessoas à sua câmera. Basta que a pessoa baixe o aplicativo IPC 360 e realize o cadastro. Quando você for compartilhar essa câmera, basta colocar o e-mail que a pessoa usou para se cadastrar e pronto. Aparecerá a camera no aplicativo da pessoa.

Essa a tela de capturas. Todas as fotos ou vídeos feitos atraves do aplicativos serão listados aqui agrupados pela data.

Essa tela salva todas as imagens que dispararam o alarme da câmera. Para quem não conhece, as câmeras IP's possuem um mecanismo de alarme. Quando acontece algum movimento na imagem da câmera, ela bate uma foto e notifica o responsável pela câmera. É muito útil para segurança.

Essa é a tela de configuração. Há várias configurações e é levar ir mexendo para aprender.
Cansei..
Falou valeu

Wildfly: entendendo suas extensões

A idéia desse post é explicar como funciona as "extensions" do JBoss Wildfly, que são módulos criados para implementar toda a spec Java EE e outras funcionalidades.

Desde a primeira versão Wildfly, o servidor sofreu uma grande mudança em sua estrutura interna que passou a contar com um core leve e extensões que são carregadas conforme necessidade ou por escolha do desenvolvedor.

• Infinispan: esse módulo é uma implementação de provider de cache de segundo nível. Segundo a própria documentação do Wildfly: "provê suporte a cache para serviços de alta disponibilidade: alta performance, cache transacional que pode operar com sistemas distribuídos e não distribuídos".
• ConfigAdmin: (ler sobre módulo OSGi) esse módulo aparece nos wildfly 7.X até a versão 8.0.0-Alpha2 e ao que tudo indica era o módulo que implementava a spec de OSGi. Segundo o site da JBoss, o módulo de OSGi foi externalizado e por isso deixou de aparecer no standalone.xml.
• Connector: não encontrei nada sobre esse módulo. Caso alguém saiba e queira comentar sobre...
• deployment-scanner: esse cara é mais uma funcionalidade do sistema do que necessariamente um módulo. Ele funciona apenas quando o servidor está sendo rodado no modo standalone. Sua função é verificar de tempos em tempos se houve alguma alteração dentro da pasta deployments (pasta padrão de deploy do wildfly no modo standalone) e então realizar o deploy das alterações. Esse link tem uns tópicos legais sobre o deploy no modo standalone
• EJB3: essa nem precisa falar nada né ? Mas pensando bem é sempre bom falar das versões da spec do EJB que foram implementadas em cada versão do wildfly. No JBoss 7.X o EJB segue a especificação versão 3.1, enquanto wildfly 8, 9 e 10 seguem a última versão do EJB que é a 3.2 (final release em maio de 2013). Mais novidades sobre a JSR 345 aqui
• JAX-RS: essa também não. Implementação da spec de webservices através de acesso RESTful
• JDR: acrônimo para JBoss Diagnostic Reporter: pode ser rodado através do jdr.bat ou jdr.sh que está na pasta bin do servidor. Coleta vários dados do servidor fazendo inclusive cópia de arquivos de configuração para análise e dos projetos "deployados". Utiliza por padrão a porta 9990 e o melhor é que pode ser utilizado com o servidor rodando ou parado (no entanto coletará mais informações com o servidor rodando).
• JMX: acrônimo para Java Management eXtensions. É utilizado, e muito útil (diga-se de passargi), para monitoramento e configuração de aplicações de forma remota. Com JMX voce pode "controlar" à distancia, mudar valores de configuração da aplicação sem precisar parar o servidor e tudo mais. É muito bom pra acompanlhar a aplicação de produção na pós-implantação
• JPA: esse tambem não precisa falar. No entanto algo interessante de saber sobre a JPA do JBoss é que até o jboss-7.X o padrão é a implementação do JPA 2.0 já que o servidor atende às especificações da plataforma Java EE 6. Já nos wildfly do 8 pra cima, o suporte é à JPA 2.1. Mas nada impede voce de dizer para o JBoss excluir esse módulo na subida da sua aplicação (através do jboss-deployment-structure.xml) e subir sua própria JPA 2.1 como dependencia do projeto.
• JSF: esse também despensa apresentações. No JBoss 7.X o jsf não é apresentado como um módulo de forma separada, ele faz parte do módulo web. Já nas versões do wildfly 8 pra frente, ele já possui o módulo separado chamado JSF. Aqui vale chamar atenção para as versões dessa spec que os jboss implementam. Desde o JBoss Wildfly 7.X a versão é de implementação do JSF é a 2.1.7. Já no wildfly 8, 9 e 10 (server Java EE 7 certified) a versão de implementação é a 2.2. Quando sair um wildfly Java EE 8 certified (provavelmente a versão 11), aí a implementação do JSF será a 2.3. No entanto a versão 8 da plataforma tem tambem a spec do MVC 1.0 que está extremamente interessante. Vale a pena olhar.
• logging: esse módulo é mais uma facilidade para o desenvolvedor que não precisa se preocupar com API's de log. O próprio servidor te fornece essa api. Se o desenvolvedor não quiser mudar as configurações padrões de log do servidor, basta adicionar nenhum arquivo de configuração. Nesse caso, as configurações padrões ficam definidas dentro do seu próprio standalone.xml. Caso queira personalizar a geração de log, basta por um dos arquivos de configuração abaixo (o servidor irá procurar os arquivos nessa ordem):
• logging.properties
• jboss-logging.properties
• log4j.properties
• log4j.xml
• jboss-log4j.xml
• mail: API de emails do Java. Segue abaixo as versões do servidor e as versões da API utilizadas:
• JBoss 7.X utiliza a versão 1.4.4
• Wildfly 8.1.0 utiliza a versão 1.5.1
• Wildfly 9.0.2 utiliza a versão 1.5.3
• Wildfly 10.X utiliza a versão 1.5.5 (última versão da API)
• naming: Esse subsystem de naming, serve para definirmos objetos para lookup JNDI e a partir do wildlfy 8 (naming versão 2) permite habilitar ou desabilitar lookup JNDI remoto. Nesse link da jboss dá pra olhar exemplo das 4 formas de definir lookups:
• Simple
• Object-Factory
• External-Context
• Lookup
• OSGi: mesmo do ConfigAdmin. Ainda estou pesquisando sobre, mas parece que os dois trabalham juntos.
• POJO: Habilita o deploy de aplicações contendo JBoss Microcontainer Services (suportado pelas versões anteriores do servidor
• remoting: é o sub-sistema de comunicação remota do servidor. Através dele o wildlfy faz os look-ups remotos e acesso a EJB's remotos.
• SAR: Habilita o deploy de arquivos .sar que eram suportados em versões mais antigas do servidor. Os arquivos sar são um compactado como um war ou jar que possui MBeans internos. SAR significa Service Archive
• Security: 
• Transactions: Implementação do JTA (Java Transaction API) com o JBoss 7.X implementando a versão 1.1 e o wildfly 8, 9 e 10 implementando a versão 1.2
• Webservices: Esse módulo utiliza o Apache CXF para suporte ao JAX-WS (Construção de webservices com SOAP). A última versão do wildfly até o momento (10.1.0.Final) utiliza o Apache CXF 3.1.6.
• Weld: Implementação do CDI

Aí você me pergunta... pra que eu preciso de saber sobre isso ?
É simples. Por 3 motivos que considero bastante importantes:

1) Migração de aplicação: Quando você tem que fazer a migração do servidor do Wildfly 8 para 10 (como já foi meu caso). É extremamente importante você saber quais as versões das Specs da plataforma EE, os servidores implementam. Isso vai dar uma boa ajuda na hora de migrar aplicação.
2) Otimização do servidor: Muitas pessoas sobem o servidor com standalone-full.xml e nunca ao menos se perguntaram qual a diferença entre o standalone.xml e o standalone-full.xml. E pior... caso você utilize o Spring ao invés do Java EE, voce pode criar seu próprio arquivo standalone customizado subindo apenas os módulos que sua aplicação irá utilizar. Dessa forma, o servidor não precisa carregar um monte de coisas que não serão utilizadas (sim, eu sei que vários serviços ficam no modo passivo)
3) Desenvolvimento da aplicação EE: Caso você opte por criar uma aplicação que utilize as especificações da plataforma EE e vá utilizar os jars disponíveis no servidor de aplicação, é necessário que você saiba quais as versões das API's serão utilizadas. A vantagem nesse caso é que seu artefato (war ou ear) ficará com um tamanho extremamente reduzido.

Montar pasta de rede windows no CentOS via linha de comando

Bom dia pessoal.

Esse post vai pra quem acessa servidores corporativos linux e por isso não possuem interface gráfica.

Meu caso é exatamente esse. Primeiramente vou contar um pouco mais do problema:
O cliente liberou acesso à máquina de produção através do IP da empresa que trabalho. Ou seja, essa máquina só é visível a partir de conexões que saem da empresa que trabalho. No entanto, não quero ter que vir para a empresa sempre que precisar acessar essa máquina de produção para fazer deploy de um sistema.
Logo, coloquei um cliente SSH no celular. Pelo celular me conecto à uma máquina linux da empresa e então estabeleço nova conexão SSH à máquina de produção. Mas normalmente o arquivo que preciso fazer deploy fica em uma pasta de rede (máquina windows). Então, segue o fluxo:

1. Efetuar conexão SSH à uma máquina linux da empresa
2. Copiar artefato do deploy da máquina da empresa para a máquina de produção
3. Acessar máquina de produção
4. Fazer o que precisa

Acima tem um diagrama de como a conexão é feita:

1. O cliente SSH estabelece conexao com o gateway da empresa através do IP externo (186.246.152.60)
2. No gateway há uma regra desviando toda conexão SSH (porta 22) para a máquina interna 192.168.12.50
3. Efetua login na máquina de IP final 50 e faz a cópia do arquivo do servidor 192.168.12.83 via scp.
4. Faz a copia do artefato para o servidor de produção.

Agora vem o motivo desse post. Estabelecer conexão a partir da máquina 192.168.12.50 (Linux CentOS) com a pasta pública da máquina 192.168.12.83 (Windows) para a cópia do arquivo.

Primeiro precisaremos baixar os pacotes do samba que é o programa que simula um servidor Windows permitindo troca de arquivos em uma rede Microsoft. Como estamos no CentOS, utilizaremos o comando sudo yum install samba-client samba-common cifs-utils.

Agora vamos configurar a pasta publica do windows (192.168.12.83) no linux (192.168.12.50).

Essa configuração é feita no arquivo /etc/fstab conforme mostra a figura abaixo:

No que na ultima linha do arquivo, declaramos que a pasta de rede está na máquina de IP 192.168.12.83 e com nome Pub. Tambem precisamos configurar o usuário e senha que possui acesso à pasta. Demos o identificador /mnt/thiago para essa pasta que é também o local onde ela será montada.

Agora vamos ao Windows para criar, compartilhar e dar permissão à nossa pasta Pub.

A pasta Pub foi criada no C:

1. Ir até C:
2. Criar pasta Pub
3. Clicar com botão direiro em cima da pasta e Propriedades
4. Clicar na aba Compartilhamento
5. Clicar no botão Compartilhar

Agora selecionaremos os usuários de rede que terão acesso à essa pasta. No meu caso, a máquina Windows pertence ao usuário thiago. Logo não será necessário dar permissão ao usuário thiago pois ele já é proprietário.

Com as permissões configuradas para o usuário thiago, criaremos a pasta /mnt/thiago no linux. Aí basta montarmos a pasta de rede com o comando mount /mnt/thiago. Internamente o linux irá olhar no arquivo /etc/fstab se há algum mapeamento para /mnt/thiago. Ele irá achar a linha que adicionamos ao final do arquivo. Irá tentar acessar atraves do samba o IP com usuario e senha declarados e pronto! Pasta de rede montada no linux.

Qualquer dúvida é só postar aí nos comentários que a gente dá um jeito.

Caso você seja usuário final e queira fazer toda essa integração com a interface gráfica, segue um tuorial muito bem feito: https://www.todoespacoonline.com/w/2015/06/compartilhamento-de-arquivos-entre-linux-e-windows/

Abraço.

Disponibilizando o servidor na porta 80

Esses dias tive que reconfigurar meu servidor (um droplet do digitalocean) e me deparei com um problema antigo. Configurar o servidor na porta 80. Obviamente isso é extremamente básico de se fazer MAAAAAS a maioria das pessoas coloca o sistema em risco quando faz isso.

Primeiramente, porque colocar o servidor na porta 80 ? Os servidores Java que baixamos vem por default rodando na porta 8080 que é uma porta secundária destinada ao protocolo HTTP. Já o servidor padrão do ruby e do nodejs rodam na porta 3000. É uma questão básica de escolha. No entanto se você acessar um site que roda em um servidor configurado na porta diferente da porta 80, você deverá declará-la. Imagine como seria chato acessar o G1 com a url www.g1.com.br:8080. Isso sem contar que você deveria saber qual a porta cada site está rodando. Pra facilitar a vida, convencionou-se que a porta padrão HTTP seria a 80 e caso a porta fosse omitida, então significa que deve-se usar a porta padrão. Resumindo, digitar www.g1.com.br é a mesma coisa que digitar www.g1.com.br:80 . Massa né ? Pode tentar... Ambas funcionarão.

Os sistemas operacionais se comunicam com outros programas através de portas que vão da porta 1 até a porta 65 mil e alguma coisa... No entanto as primeiras mil portas são especiais pois são usadas pelo sistema operacional. Logo, para rodar um programa usando uma dessas portas, precisamos de duas coisas: que a porta não esteja sendo usada e usar a conta de administrador. É aí que começa o problema...

Quando você utiliza a conta de administrador pra iniciar o servidor na porta 80, o processo roda com os privilégios do administrador. CASO você seja vítima de um ataque de shell reverso por exemplo, o atacante poderá fazer absolutamente tudo na sua máquina. Nenhum arquivo será poupado de um ataque com privilégios de administrador. Percebe o tamanho do problema ? Ainda mais sendo tão simples de arrumar.

Ao meu ver, a forma mais simples de arrumar é com o firewall. Você roda o seu servidor com um usuário comum e com privilégios limitados AND na porta 8080 e usa o firewall pra redirecionar o tráfego da porta 80 pra porta 8080. Simples assim! Vou explicar melhor... Você coloca seu site rodando na porta 8080. Pra acessá-lo, bastaria digitar www.meusite.com.br:8080. Quando essa requisição chegar no servidor, o firewall a processará antes de passar para o servidor. No momento que o firewall ver que é uma requisição para a porta 80, ele irá mudar pra porta 8080. Com isso a requisição irá para nosso servidor e o usuário nem vai saber que estamos rodando o servidor na porta 80.

Para fazer essa configuração, vamos começar instalando o iptables (para isso precisamos do root).

Caso seu sistema já esteja com o iptables instalado e atualizado, exibirá uma mensagem igual a essa. Caso não esteja instalado, o apt-get irá baixar os pacotes necessários e instalar. 

Agora para configurar o redirecionamento da porta 80 pra porta 8080, basta digitarmos o seguinte comando:

iptables -A PREROUTING -t nat -i eth0 -p tcp --dport 80 -j REDIRECT --to-port 8080

Feito isso, todos pacotes do protocolo TCP vindos pela interface de rede eth0 com porta de origem 80, serão redirecionados para a porta 8080. E o melhor. Caso o sistema seja invadido, o máximo de estrago possível de causar estará de acordo com as permissões que VOCÊ deu para o usuário. Então, veja lá. Abraço !

Assinando Documentos Digitalmente (e-CPF, e-CNPJ)

Após escrever bastante, achei melhor já colocar essa frase logo no começo:

Certificados digitais existem para você assinar um documento digitalmente e ninguém ter como fraudá-lo ou alterá-lo.

O objetivo desse artigo é demostrar como assinar documentos digitalmente. Primeiramente vou falar um pouco da teoria envolvida no assunto e vou mostrar como fazer isso programaticamente utilizando a linguagem Java.

Antes de começar a falar de assinatura de documentos digitais, precisamos entender alguns conceitos importantes como criptografia de chaves públicas, funções hash e PKI. Mas vou explicar de uma forma bem básica para ficar de fácil entendimento. Logo, se voce já dominar o assunto, tenha isso em mente (pra não ficar me enchendo o saco nos comentários).

A criptografia assimétrica é uma criptografia que utiliza um par de chaves (uma chave pública e uma chave privada) para criptografar um texto. A chave privada é a mais importante e deve ser mantida e sigilo, enquanto a chave pública pode ser distribuída livremente. Tudo que é criptografado com a chave privada, só pode ser descriptografado com a chave pública, e tudo que é criptografado com a chave publica só pode ser descriptografado com a chave privada.
Tendo isso em mente, vamos a uma simples demonstração de como funciona a criptografia assimétrica (que é usada hoje em dia)

Temos acima uma imagem que ilustra mais ou menos como funciona o processo... A imagem foi retirada do site www.rtell.com.br e estou indicando só pra eu não tomar fumo com autoria de imagem... Nem sei sobre o que é o site.

João e Maria querem conversar sem que ninguém consiga ler a conversa. Então cada um entrega sua chave pública para o outro. Quando João escreve uma mensagem, ele criptografa a mensagem com a chave pública de Maria. Assim a única forma de descriptografar a mensagem, é com a chave privada de Maria. Como apenas Maria tem essa chave, apenas ela poderá descriptografar e ler a mensagem escrita por João. Seguindo a mesma lógica, quando Maria escrever pra João, ela irá criptografar com a chave pública de João pois apenas ele tem a chave privada para descriptografar. Caso uma chave privada vaze, tudo que foi escrito usando a chave pública que é par desta chave, poderá ser descriptografado. Logo, a chave privada tem que ser guardada da forma mais segura possível.

Entendido como funciona a criptografia assimétrica, vamos para as funções HASH.
As funções HASH são o mais simples possível. Sua única finalidade é fazer um resumo. Quando uma função hash é aplicada a um arquivo, ele gera um resumo do arquivo, de forma que se um byte for alterado, esse resumo deve ser completamente alterado. Existem vários algoritmos de hash como MD5, SHA-1, SHA-512 e uma caralhada de outros.

Observações importantes sobre hash:

• O hash é uma função de mão única. Depois que um arquivo é resumido, não é possível voltar ao arquivo original (ou teríamos o melhor compactador do mundo)
• A diferença entre cada função é o tamanho do resumo gerado e a função para gerar esse resumo. Por exemplo: o MD5 gera um resumo de 128 bits, o SHA-1 gera um resumo de 160 bits, o SHA-512 gera um resumo de 512 bits.
• Colisões acontecem quando um algoritmo hash gera o mesmo resumo para arquivos diferentes (sim, isso acontece mas quanto melhor o algoritmo, mais difícil é de acontecer)

Pronto. Agora que esses dois pontos já estão explicados, podemos entender o que é a assinatura digital de documentos.

Vamos supor que fiz um documento em pdf e quero assiná-lo digitalmente.

1. Primeiro eu aplicamos uma função hash para conseguir um resumo do meu documento
2. Depois aplicamos uma algoritmo de criptografia (RSA, AES, DES, 3-DES) no modo cifragem usando minha chave privada no resultado da função de hash utilizada no passo 1. O resultado dessa operação de cifragem é a nossa assinatura digital (essa chave privada está dentro do certificado digital).
3. Agora monto um arquivo contendo nosso arquivo original (usado no passo 1) mais o resultado da cifragem (gerado no passo 2).

Pronto. Temos um arquivo assinado e esse simples processo é chamado de assinatura digital.

Pontos importantes a serem observados:

• A assinatura digital garante a autoria da mensagem pois é usada a chave privada para assinar
• Caso estivéssemos assinando um documento txt, após gerar o documento assinado conseguiríamos ler o documento. Isso acontece pois a assinatura digital não realiza criptografia do conteúdo do documento. No final do arquivo, também veríamos dados ilegíveis que foram gerados nos passos 1 e 2.
• Vamos supor que uma terceira pessoa altere meu documento (o que chamamos de falsificação). Para verificarmos se o conteúdo do arquivo está válido, realizaremos o processo de assinatura digital novamente: 
• Primeiro pegamos a assinatura digital do arquivo.
• Depois deciframos com a minha chave pública. Esse passo irá me retornar o HASH do documento original.
• Por último realizamos o HASH do documento. Esse hash deverá ser igual ao resultado gerado no passo 2. Se o resultado for o mesmo, o arquivo está válido. Se der um resultado diferente, teremos a certeza que o conteúdo do arquivo foi modificado. E isso só acontece pois ao alterar o texto, a função hash gera um valor completamente diferente.

Estava procurando uma imagem para ilustrar esse passo a passo e encontrei esse blog que também está falando um pouco sobre assinatura digital (como conhecimento nunca é demais, vale a pena ler...)

Agora, antes de entrarmos na programação, vamos apenas entender sobre os certificados A1 e A3 que usaremos para assinar um documento digitalmente. Já viu cartório ? Aquela putaria que é pra reconhecer firma de documento e tudo mais ? A ideia de ambos é fazer o que o cartório faz mas de forma eletrônica. É realizar o processo descrito na imagem acima. Sabe a chave privada que é usada na imagem acima pra criptografar ? Essa chave fica guardada dentro do certificado digital.

O certificado A3 é um documento físico (um cartão na verdade) que possui dados referentes ao seu dono, bem como sua chave privada. Já o certificado A1, é um documento digital mas que também possui todos os dados que o A3 possui.

Na imagem acima temos um certificado digital de pessoa jurídica. O certificado de pessoa física é exatamente igual mas com o escrito e-CPF. Ambos contem informações sobre uma pessoa (e-CPF) ou sobre uma empresa (e-CNPJ) bem como a chave privada.

Continuando, vamos entender agora esse framework demoiselle.

Esse framework foi criado pelo SERPRO (Serviço Federal de Processamento de Dados) com o intuito de facilitar a utilização de assinatura eletrônica através da linguagem Java. A versão 1 que usei é muito boa pois se propõe a fazer isso e ponto. Já a versão 2... não entendi qual a ideia do pessoal do SERPRO ao envolver toda a plataforma EE 6 no meio de um simples processo de assinatura digital. Ao meu ver, a versão 1 foi disponibilizada como uma API e a versão 2 foi disponibilizada como framework (o que não me agrada muito). Mas vamos deixar isso de lado e partir para o que interessa...

Desde a versão 1 do demoiselle, as libs estão disponibilizadas no repositório central do maven. Então vamos fazer esse projeto já com maven.

O objetivo será gerar um programa para a plataforma Java SE que realize a assinatura digital de um documento PDF. Após isso, iremos transformar esse programa em um applet para ser usado através de sistemas web para os clientes consigam assinar documentos (vale lembrar que esse mês - setembro de 2015 - o Chrome removeu todo suporte a applets Java. Logo, as versões mais atuais desse navegador não executarão nosso applet). Vamos então ao desenvolvimento:

• Criar projeto com maven e adicionar libs do demoiselle:

Uma dica: utilize o archetype maven-archetype-simple ou o maven-archetype-quickstart para gerar o projeto e adicione as dependencias do demoiselle no pom.xml deixando-o assim:

Arquivo pom.xml com dependências do demoiselle

• Adicionar código para leitura dos certificados. Leitura de certificados A1 e A3:

Primeiro vamos diferenciar os dois certificados nesse passo. Os certificados A1 (cartões físicos), exigem uma senha para podermos acessar seus dados. Logo, essa senha tem que ser informada para o nosso programa em tempo de execução. O demoiselle já facilita nossa vida novamente com a classe PinCallbackHandler que irá apresentar uma caixa de texto exigindo a senha quando necessário.

Código fonte para leitura das informações do certificado digital

Callback para informar a senha do certificado A1 (cartão)

Nota importante: se você olhar o código fonte do demoiselle, ele faz uma busca por vários drivers para tentar fazer a leitura dos certificados A1. Caso não apareça essa caixa para introduzir a senha (PIN), verifique se o driver do dispositivo está instalado.

Nota do editor (sempre quis escrever isso): Sempre que eu vejo código na internet, é código porco. Não tem como copiar código da internet sem ter que refatorar tudo. Hoje entendo porque. Puta preguiça de fazer código pra não ganhar nada com isso. Ou seja, refatorem esse código safado que estou escrevendo. Mas já que comecei esse inferno de post, o jeito é terminar...

• Assinar digitalmente um documento pdf:
• Transformar em Applet:
• Assinar o applet com nosso certificado para o browser não mostrar mensagem de risco:

OBS.: O texto ainda está em construção. Devo terminar ainda essa semana

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

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...