Tenho feito muitos testes para utilizar TLS e mTLS. TLS é uma camada de criptografia assimétrica para garantir a comunicação segura entre dois pontos.
Em geral temos o model parecido com os sites web onde o servidor tem uma conexão segura assinada por uma autoridade certificadora e nos conectamos a ele. No caso de mTLS, mutual TLS, é preciso validar quem conecta também.
Pra gerar os testes que venho fazendo, gero um certificado de 1 dia usando openssl da seguinte forma:
openssl req -x509 -newkey rsa:4096 -keyout key.pem -out cert.pem -days 1 -nodes \
-subj "/C=SE/ST=Stockholm/L=STHLM/O=Company/OU=ADP/CN=localhost
Esse comando gera para mim a chave do servidor (key.pem) e a chave da autoridade certificadora, que assina a chave.
Em geral carrego isso no meu programa que utiliza TLS.
Pra testar (assumindo que seu serviço seja http e esteja usando a porta 9091):
curl --cacert cert.pem --key key.pem --cert cert.pem "https://localhost:9091/
Eu poderia gerar um chave pro client, que no caso é o comando curl, mas como é pra ambiente de testes, re-uso o mesmo.
Boa diversão!
Diversas vezes preciso gerar gráficos em meu trabalho diário. Uma excelente ferramenta, que nem sempre recebe os devidos créditos, é gnuplot . Entre as facilidades do gnuplot estão a forma de enviar comandos, que pode ser via batch, o que cria a possibilidade de utilização em scripts, e a leituras de dados em arquivo texto.
Num mundo cada vez mais sedento por dados e uso massivo de bancos de dados, pode parecer ridículo o uso de aquivos textos para guardá-los. Infelizmente vários scripts que desenvolvi e uso, alguns somente para ler a porcentagem de uso de CPU, salvam em formato texto. Parte poderia ser atribuída a minha mediocridade em programação, mas nem sempre tenho disponível os pacotes de integração para comunicação com BD nas plataformas que monitoro. ??s vezes nem BD pode ser instalado para isso. Nesses casos o arquivo texto serve muitíssimo bem.
Para quem já utilizou a solução de SSLVPN da Juniper, sabe que é preciso mapear as portas para seu uso (no meu FreeBSD não funciona o modo de tunelamento).
Como vários serviços são acessiveis via portas baixas, incluindo ssh, ftp, telnet, etc, existe a possibilidade de mapear as portas acima de 1024 nas portas baixas através de vários ips de loopback.
O script abaixo gera o arquivo rinetd.conf para as várias interfaces :-)
#! /bin/sh
CONF="/usr/local/etc/rinetd.conf"
PORTS="110:11000 25:2500 443:44300 80:8000 22:2200 23:2300 21:2100 20:2000"
### Commands here ###
TMSTAMP=`date "+%Y%m%d"`
if [ -f $CONF ]; then
mv $CONF $CONF-$TMSTAMP
fi
IPS=`ifconfig lo0 | grep netmask | awk '{print $2}'`
for ip in $IPS
do echo "Configuring: $ip"
for port in $PORTS
do
LOW_PORT=`echo $port | awk -F":" '{print $1}'`
HIGH_PORT=`echo $port | awk -F":" '{print $2}'`
echo -e "$ip $LOW_PORT \t $ip $HIGH_PORT" >> $CONF
done
done
Nada como os desafios para nos fazer acordar. Meu desafio foi criar um sistema de monitoração de performance para sistemas pré-pago. Com RRDTool na mão e perl na cabeça, lá fui eu. Não que eu seja exímio programador em Perl (ou qualquer outra linguagem), mas os sistemas de telefonia, principalmente na parte de pré-pago, usam sistemas Solaris 9.0, onde perl já vem instalado.
O resultado, já nesses gráficos, ficou além do esperado e pronto em 5 dias!!! Haja código... já sobre a documentação... essa virou parte das lendas como boi-tatá, saci pererê...
O primeiro gráfico mostra as verificações de crédito para liberar a chamada (First Interrogation), assim como os débitos (Final Report). O segundo, chamadas originadas (celular ligando para alguém) dentro da própria rede da operadora.
Dica retirada de http://www.network-theory.co.uk/docs/cvsmanual/cvs_53.html.
Em alguns trabalhos cooperativos, sempre que baixo uma versão específica do cvs, utilizando algo como "cvs checkout -r1.1 programa", acabou com um erro de "sticky tag" ao fazer o novo commit.
Pelo link acima vi que basta usar um "cvs update -A" para resolver isso.
