DNS da google com problemas para resolver nomes da árvore mg.gov.br

Pessoal,

ainda não descobri o porque do problema mas gostaria de compartilhar com vocês que os servidores dns da google (8.8.8.8 e 8.8.4.4) não estão conseguindo resolver nada que está abaixo da árvore mg.gov.br. Caso precisem acessar algum domínio do Estado de Minas gerais usem outro servidor dns que não seja o da google.

Att.

Leonardo Gomes Duarte

Configurando SSL no servidor de aplicação Tomcat/JBOSS – Aceitar conexões SSL somente se o cliente apresentar um certificado válido

Prezados leitores,

há algum tempo não escrevo nada e não alimento o blog com informações.

Quando criei este blog não tinha ideia do quanto é necessário tempo para manter as informações daqui em dia. Como todos vocês devem saber tempo é uma coisa cada vez mais rara e comigo não é diferente. Devemos nos manter sempre atualizados para garantir empregabilidade e competitividade neste nosso mercado de tecnologia e para isto é necessário muito estudo e dedicação e com isto as prioridades surgem e acabamos deixando várias coisas de lado. Bom, agora que justifiquei minha ausência por este longo período vamos ao que interessa realmente.

Neste post irei detalhar e apresentar um “how-to” para configurar seu servidor de aplicações tomcat para aceitar conexões “ssl” (Secure Socket Layer) apenas se o “client” apresentar um certificado válido emitido e assinado pela sua própria “CA” (Certificate authority).

Vamos ao “how-to”:

1 – Criar diretórios:

CA e dentro do diretório CA criar os diretórios private e newcerts

2 – Criar, dentro do diretório CA, a base de dados e o arquivo de índice para os certificados que vamos assinar:

echo ’01’ > serial

touch index.txt

3 – Criar, dentro do diretório CA, um arquivo de configuração openssl.cnf com o seguinte conteúdo:

#

# OpenSSL configuration file.

#

# Establish working directory.

dir = .

[ ca ]

default_ca = MINHA_CA

[ MINHA_CA ]

serial = $dir/serial

database = $dir/index.txt

new_certs_dir = $dir/newcerts

certificate = $dir/cacert.pem

private_key = $dir/private/cakey.pem

default_days = 365

default_md = md5

preserve = no

email_in_dn = no

nameopt = default_ca

certopt = default_ca

policy = policy_match

[ policy_match ]

countryName = match

stateOrProvinceName = match

organizationName = match

organizationalUnitName = optional

commonName = supplied

emailAddress = optional

[ req ]

default_bits = 1024 # Size of keys

default_keyfile = key.pem # nome das chaves que serao criadas

default_md = md5 # algoritmo de digest utilizado

string_mask = nombstr # tipo de caracteres permitidos

distinguished_name = req_distinguished_name

req_extensions = prefeituras_req

[ req_distinguished_name ]

# Variable name Prompt string

#———————- ———————————-

0.organizationName = Organization Name (company)

organizationalUnitName = Organizational Unit Name (department, division)

emailAddress = Email Address

emailAddress_max = 40

localityName = Locality Name (city, district)

stateOrProvinceName = State or Province Name (full name)

countryName = Country Name (2 letter code)

countryName_min = 2

countryName_max = 2

commonName = Common Name (hostname, IP, or your name)

commonName_max = 64

# Valores padrao para evitar digitar tanto.

# Variable name Value

#————————————————————

0.organizationName_default = MINHA_CA

localityName_default = Belo Horizonte

stateOrProvinceName_default = Minas Gerais

countryName_default = BR

[ CA_PARTICULAR ]

basicConstraints = CA:TRUE

subjectKeyIdentifier = hash

authorityKeyIdentifier = keyid:always,issuer:always

[ prefeituras_req ]

basicConstraints = CA:FALSE

subjectKeyIdentifier = hash

Rode dentro do diretório CA:

openssl req -new -x509 -extensions CA_PARTICULAR -keyout private/cakey.pem -out cacert.pem -days 3650 -config ./openssl.cnf

Este comando vai gerar dois arquivos, são eles:

Uma chave privada em private/cakey.pem .

Um certificado raiz CA cacert.pem.

Obtendo informações do certificado gerado:

openssl x509 -in cacert.pem -noout -text

Informação sobre datas de criação e expiração:

openssl x509 -in cacert.pem -noout -dates

Informação da finalidade do certificado:

openssl x509 -in cacert.pem -noout -purpose

Criar as requisições de assinatura:

openssl req -new -nodes -out req.pem -config ./openssl.cnf

Este processo irá gerar dois arquivos:

Uma chave privada chamada key.pem

Uma requisição de assinatura de certificados req.pem

Renomear os arquivos acima. Colocar um nome sugestivo:

mv key.pem chave_privada-key.pem

mv req.pem chave_publica-req.pem

certificado_assinado.pemVerificar informações da requisição com o comando abaixo:

openssl req -in chave_publica-req.pem -text -verify -noout

Assinar a requisição:

openssl ca -out certificado_assinado.pem -config ./openssl.cnf -infiles chave_publica-req.pem

Este comando acima atualizou a database CA (index.txt) e produziu dois arquivos:

O certificado certificado_assinado.pem

A cópia do certificado newcerts/01.pem

Gerar o arquivo pkcs12 (pfx) e pkcs7 (JKCES) para a inclusão no servidor de aplicação tomcat ou no browser:

openssl pkcs12 -export -in certificado_assinado.pem -inkey chave_privada-key.pem -out CERTIFICADO-pkcs12.pfx

keytool -genkey -alias MINHA_CA -keyalg RSA -validity 7 -keystore MINHA_CA.jks

keytool -import -alias cacert -keystore MINHA_CA.jks -trustcacerts -file cacert.pem

*Atentar para os certificados usados no comando, todo certificado que for assinado deverá ser inserido neste keystore com o comando (keytool -import -alias certificado1 -keystore MINHA_CA.jks -trustcacerts -file certificado1.pem) para que o tomcat confie no mesmo.

Revogar certificados:

openssl ca -revoke newcerts/cert.pem -config ./openssl.cnf

Configurar TOMCAT/JBOSS:

Edite o arquivo server.xml e adicione/altere a lina como demonstrado abaixo:

Linha necessária no conf do JBOSS e TOMCAT para forçar a solicitação de um certificado válido para estabelecer a conexão:

<Connector acceptCount=”100″ clientAuth=”true” disableUploadTimeout=”true” enableLookups=”false” keystoreFile=”caminho_para_o_arquivo_pfx” keystorePass=”senha” keystoreType=”PKCS12″ maxHttpHeaderSize=”8192″ maxSpareThreads=”75″ maxThreads=”150″ minSpareThreads=”25″ port=”443″ scheme=”https” secure=”true” sslProtocol=”TLS” truststoreFile=”caminho_para_o_arquivo_jks” truststorePass=”senha” truststoreType=”JCEKS”/>

Bom pessoal, espero que seja útil para alguém. Lembro que tive que estudar muito para fazer isto funcionar e para chegar nesta documentação na época em que fui mexer com isto pela primeira vez.

Forte abraço a todos e até a próxima.

Att.

Leonardo Gomes Duarte

Que tipo de lâmpada usar em sua casa?! Lâmpadas Microsoft?! Será?!

… (lâmpada Microsoft)
– Ao instalar uma lâmpada Microsoft em sua casa, todas as demais queimariam, pois lâmpadas Microsoft sempre supõem ser a única lâmpada da casa
– Ao instalar uma lâmpada não original, cada vez que você a acendesse, apareceria uma mensagem na frente do interruptor, avisando das grandes vantagens de se adquirir uma lâmpada Microsoft genuína
– Essa lâmpada atrai muito mais insetos, vírus e vermes do ambiente, ficando em pouco mais de seis meses tão encardida com coisas grudadas nela tão firmemente, na prática impedindo que a luz dela seja vista, de forma que é melhor trocar por uma nova do que tentar limpar
– Frequentemente a lâmpada pararia de responder aos comandos do interruptor, se recusando a desligar, precisando ser retirada do bocal e recolocada, ou desligar o disjuntor da casa
– A cada semana você precisaria atualizar sua lâmpada para mantê-la segura, evitando execução de “níveis de corrente arbitrários”, que poderiam danificar sua lâmpada, e até mesmo outros eletrodomésticos

motorola a3100

adquiri e estou testando este smartphone da motorola, ate o momento estou achando muito melhor do que o htc que eu tinha.

Qual distribuição Linux usar?

Boa noite caros leitores,

descobri um link muito interessante em uma comunidade linux que faço parte e gostaria de compartilha-lo no meu blog.

Hoje em dia a maior birra dos usuários que resolvem começar o uso do S.O Linux é na hora de escolher qual distribuição utilizar. Existem muitas, mas muitas distribuições no mercado e realmente ficamos confusos na hora de adotar uma distro.

Para aqueles que estão com este problema que é de muita gente segue o link para tentarem descobrir qual distro de adapta melhor a você:

http://www.zegeniestudios.net/ldc/index.php?lang=pt-br

Att.

Leonardo Gomes Duarte.

Hardening – SSH

Para o hardening de ssh devemos:

Permitir acesso usando o protocolo SSHv2 somente, isto é feito editando o arquivo /etc/ssh/sshd_config e trocando a linha:

#PROTOCOL 1,2

para:

PROTOCOL 2

Criar um grupo para usuários que podem acessar o servidor remoto, e desabilitar o login do root no SSH:

vi /etc/ssh/sshd_config

#AllowUsers root

or

PermitRootLogin no

AllowGroups sshallow

No exemplo acima o grupo criado foi sshallow, para criar o grupo em S.O.s Linux basta digitar o comando:

#groupadd sshallow

Podemos ainda restringir os hosts/IPs que acessam o servidor remotamente. Para isto precisamos somente editar o arquivo /etc/hosts.allow e adicionar os ips : a palavra allow para os ips que queremos liberar e na última linha digitamos ALL : deny para negar qualquer outro ip que não tenha sido setado como allow ( liberado ).

sshd : 127.0.0.1 : allow

sshd : 192.168. : allow

sshd : 10. : allow

sshd : x.x.x.x : allow

sshd : x.x.x.x : allow

sshd : ALL :deny

A última linha vai restringir o acesso ao SSH de qualquer ip, liberando apenas os IPS listados acima desta linha.

Outro recurso muito interessante é o uso de chaves criptográficas para autenticação via ssh, irei escrever sobre isto posteriormente pois pretendo explicar o que são as chaves como funciona o algoritmo que as gera e ai sim, como configuramos o ssh para usa-las.

Serviços desnecessários ( Desabilite-os )

Serviços desnecessários normalmente são isntalados por padrão no seu S.O. linux, caso você já tenha seus servidores instalados remova-os e caso vá instalar algum desmarque os pacotes a seguir, pois eles provavelmente não serão utilizados e são considerados pacotes inseguros:

– rshd:

É um shell que pode ser executado remotamente quando este serviço está “startado”em seu sistema, o grande problema deste serviço é que ele não provê medidas de segurança para as execuções.

– rlogind

É um serviço que possibilita logins remotos, támbem é um serviço que não provê segurança nos acessos feitos através deste deamon.

– rwhod

Servidor de status do sistema

: Rwhod é um servidor que mantem a base de dados usada pelos programas rwho e ruptime. Essa operação esta relacionada com a habilidade de enviar mensagens ao broadcast da rede.

– telnetd

Telnetd é um servidor telnet e Telnet é um protocolo cliente-servidor usado para permitir a comunicação entre computadores ligados numa rede (exemplos: rede local / LAN, Internet), baseado em TCP.

Telnet é um protocolo de login remoto.

Antes de existirem os chats em IRC o Telnet já permitia este gênero de funções.

O protocolo Telnet também permite obter um acesso remoto a um computador.

Este protocolo vem sendo gradualmente substituído pelo SSH, cujo conteúdo é criptografado antes de ser enviado. O uso do protocolo Telnet tem sido desaconselhado, a medida que os administradores de sistemas vão tendo maiores preocupações de segurança. Com o Telnet todas as comunicações entre o cliente e o servidor podem ser vistas, inclusive senhas, já que são somente texto plano, permitindo assim que com o uso de “port-stealing” intercepte a conexão e seus pacotes, fazendo hijacking.

-ftpd

FTP significa File Transfer Protocol (Protocolo de Transferência de Arquivos), e é uma forma bastante rápida e versátil de transferir arquivos (também conhecidos como ficheiros), sendo uma das mais usadas na internet.

Pode referir-se tanto ao protocolo quanto ao programa que implementa este protocolo (Servidor FTP, neste caso, tradicionalmente aparece em letras minúsculas, por influência do programa de transferência de arquivos do Unix).

A transferência de dados em redes de computadores envolve normalmente transferência de arquivos e acesso a sistemas de arquivos remotos (com a mesma interface usada nos arquivos locais). O FTP (RFC 959

) é baseado no TCP, mas é anterior à pilha de protocolos TCP/IP, sendo posteriormente adaptado para o TCP/IP. É o padrão da pilha TCP/IP para transferir arquivos, é um protocolo genérico independente de hardware e do sistema operacional e transfere arquivos por livre arbítrio, tendo em conta restrições de acesso e propriedades dos mesmos.

– sendmail

Sendmail é um agente de transferência de correio (MTA na sigla em inglês) de código aberto: um programa para o roteamento e a entrega de correio eletrônico.

-inetd

O inetd atua como um servidor gerenciador para outros daemons. Quando uma conexão é recebida pelo inetd, ele determina para qual daemon a conexão é destinada e executa o daemon correspondente e a ele delega o socket. Executar uma instância do inetd reduz a carga no sistema de forma geral, comparado a se executar cada daemon individualmente.

Primariamente, o inetd é usado para executar outros daemons, mas diversos protocolos simples são tratados diretamente, como chargen, auth e daytime.

Swap com criptografia

É interessante e simples manter o swap criptografado, para ativar:

# sysctl vm.swapencrypt.enable

vm.swapencrypt.enable=0

# sysctl vm.swapencrypt.enable=1

vm.swapencrypt.enable: 0 -> 1

No exemplo acima, no próximo boot a configuração será perdida. Para manter a configuração edite o arquivo /etc/sysctl.conf.

# vi /etc/sysctl.conf

Modifique a linha:

#vm.swapencrypt.enable=0

Para:

vm.swapencrypt.enable=1

Kernel Flags – Hardening

Essas flags são permissões adicionais no sistema de arquivos, fugindo das permissões padrões de usuário, grupo e outros. O conceito é parecido com os atributos estendidos do Linux, pois você pode definir um arquivo como imutável, como modificável apenas por um daemon, arquivo que pode ser editado, mas não removido etc.

Existem quatro tipos de flags, elas são: sappnd, schg, uappnd e uchg.

* sappnd

Essa flag só pode ser definida ou removida pelo root. Arquivos definidos com essa flag só podem receber dados (append), mas não podem ser editados. O uso é adequado para logs do sistema. Essa flag não pode ser removido com o secure level 1 ou superior.

* schg

Essa flag só pode ser definida ou removida pelo root. Arquivos com essa flag se tornam imutáveis, não podendo ser modificados ou substituídos. Essa flag não pode ser removida no o secure level 1 ou superior.

* uappnd

O dono do arquivo ou o root podem definir essa flag. Com ela arquivos podem ser modificados, mas não removidos por outros usuários. O dono do arquivo ou o root podem remover essa flag em qualquer secure level.

* uchg

O dono do arquivo ou o root podem definir essa flag. Da mesma forma como o schg, essa flag torna o arquivo imutável, mas com a diferença que a flag pode removida em qualquer secure level pelo dono do arquivo ou root.

Uso das flags

Exemplo de um arquivo sem as flags:

# ls -lo /bsd

-rw-r–r– 1 root wheel – 6861562 Dec 16 18:15 /bsd

Definindo uma flag para o arquivo /bsd (kernel)

# chflags schg /bsd

Verificando novamente:

# ls -lo /bsd

-rw-r–r– 1 root wheel schg 6861562 Dec 16 18:15 /bsd

Removendo a flag:

# chflags noschg /bsd

# ls -lo /bsd

-rw-r–r– 1 root wheel – 6861562 Dec 16 18:15 /bsd

Lembrando que as flags schg e sappnd não podem ser removidas com o secure level 1 e 2. Para poder removê-las desses dois secure levels é preciso rebootar o sistema e entrar em modo mono-usuário (boot -s).

Arquivos interessantes do sistema para utilizar a flag schg (imutáveis).

# chflags schg /bsd

# chflags schg /etc/changelist

# chflags schg /etc/daily

# chflags schg /etc/inetd.conf

# chflags schg /etc/netstart

# chflags schg /etc/pf.conf

# chflags schg /etc/rc

# chflags schg /etc/rc.conf

# chflags schg /etc/rc.local

# chflags schg /etc/rc.securelevel

# chflags schg /etc/rc.shutdown

# chflags schg /etc/security

# chflags schg /etc/mtree/special

Pastas:

# chflags -R schg /bin

# chflags -R schg /sbin

# chflags -R schg /usr/bin

# chflags -R schg /usr/libexec

# chflags -R schg /usr/sbin

Linux ( Kernel ) – Secure Levels OpenBSD

Os Secure Levels dizem como o kernel irá lidar com a segurança do ambiente. Existem quatro níveis de segurança, são eles -1, 0, 1 e 2, e pode ser configurado no arquivo /etc/rc.securelevel.

Nível -1: Podemos dizer que o nível -1 é o nível Windows, pois não há nenhuma “feature” de segurança configurada para o kernel. Os desenvolvedores do OpenBSD não recomendam utilizar esse nível. Apenas utilize em casos de necessidade.

Nível 0: Quando o OpenBSD é iniciado pela primeira vez o securelevel 0 é usado. Esse nível também não possui segurança adicional.

Nível 1: É o padrão do OpenBSD. Nesse nível o kernel não permite a escrita direta a memória através dos devices /dev/mem e /dev/kmem. A escrita nos “Raw Disk” também é proibida e as flags schg e sappnd não podem ser removidas dos arquivos.

Nível 2: É o nível mais paranóico do sistema. Nesse nível o firewall (PF) não pode ser alterado e as configurações até mesmo do relógio do sistema são limitadas. Esse nível também inclui as características do nível 1.

O secure level pode ser definido através do comando sysctl (se estiver nos níveis -1 e 0), ou através do arquivo /etc/rc.securelevel (será preciso reiniciar o sistema).

# sysctl kern.securelevel
kern.securelevel=-1
# sysctl kern.securelevel=2
kern.securelevel: -1 -> 2

Att.

Leonardo Gomes Duarte