FreeBSD - BSD INFO

Informação sempre foi e sempre será o grande tesouro da humanidade. Algumas delas podem ser públicas e outras extremamente sigilosas. A troca de informação entre filiais de uma mesma empresa, muitas das vezes serão confidenciais e por isso existe a necessidade de recursos para que isso se torne possível.

Para que haja comunicação entre essas filiais é necessário que se tenha um meio físico por onde passará todo o fluxo de informação. A Internet é hoje o maior meio físico em comum para troca de informações e que interliga todo o mundo.

Então se temos o meio físico o que falta para uma comunicação segura e confidencial? Falta uma coisa chamada VPN (Virtual Private Network) que pode ser encriptada ou não. A definição de VPN seria a de se ter um túnel privativo interligado duas ou mais redes e apenas essas redes se enxergariam. Contudo se alguém conseguisse entrar nesse túnel teria acesso a todas as informações trafegando em texto puro. Por existir essa brecha é que utilizamos a criptografia dos dados em uma VPN com a finalidade de impossibilitar que terceiros tenham acesso ao conteúdo da comunicação.

Nesse artigo falarei sobre uma ferramenta que tem crescido muito nesses últimos anos e competindo com outras mais antigas. Seu sucesso tem se dado pela simplicidade, segurança e robustez. Irei falar aqui sobre o OpenVPN um software que nos permite criar VPNs para interligar de forma segura e simples, qualquer empresa e suas filiais. Mostrarei exemplos interligando uma empresa fictícia e suas duas filiais também fictícias.

Existe um ditado que diz: “uma imagem vale mais que 1000 palavras” e por isso vou exemplificar nosso trabalho com um desenho da rede que criaremos.

Empresa: BSDInfo matriz
Localidade: Brasil / Araruama
Bloco IP da Rede: 10.200.200.0/24
IP Público fictício: 169.169.169.1/24
IP VPN: 172.16.24.1/30

Empresa: BSDInfo filial
Localidade: Brasil / Saquarema
Bloco IP da Rede: 10.200.201.0/24
IP Público fictício: 169.169.169.2/24
IP VPN: 172.16.24.6/30

Empresa: BSDInfo filial
Localidade: Brasil / São Pedro
Bloco IP da rede: 10.200.202.0/24
IP Público fictício: 169.169.169.3/24
IP VPN: 172.16.24.10/30

Baseado nas informações acima o diagrama abaixo será usado como referência para o nosso laboratório:

Conforme o diagrama acima, faremos com que todas as redes 10.200.200.0/24, 10.200.201.0/24 e 10.200.202.0/24 possam trocar dados seguramente entre eles e utilizando a Internet como meio de transporte das informações.

Para a nossa configuração usaremos um servidor FreeBSD em cada localidade com 2 interfaces de rede em cada um deles.

Na BSDInfo Araruama (matriz) será onde configuraremos o OpenVPN como Servidor e nas filiais configuraremos o OpenVPN como Cliente.

Instalando o OpenVPN nos servidores:

Atualizando os ports:

# portsnap fetch update

Instalando o bash porque os scripts do OpenVPN são em bash:

# cd /usr/ports/shells/bash
# make install clean
# rehash

Instalando o OpenVPN:

# cd /usr/ports/security/openvpn
# make install clean
# rehash

Não precisa selecionar qualquer opção na próxima tela, mantenha o default e continue a instalação. Faça os passos acima nos 3 servidores do nosso diagrama.

Começaremos nossa configuração no servidor principal que receberá as conexões das filiais. Após a instalação do OpenVPN criaremos o diretório onde faremos as nossas configurações:

# mkdir /usr/local/etc/openvpn
# chmod 700 /usr/local/etc/openvpn

Todos os procedimentos acima deverão ser feitos em todos os servidores da VPN.

Começaremos então a configuração do servidor principal da VPN.

Para facilitar a criação de VPNs, o OpenVPN vem com uma coleção de scripts para criação dos certificados e chaves que iremos utilizar nas conexões dos clientes com o servidor.

Façamos os procedimentos abaixo para nos facilitar:

# cd /usr/local/etc/openvpn
# cp -rp /usr/local/share/doc/openvpn/easy-rsa/2.0 .
# cd 2.0
# chmod +x build-ca build-dh build-inter build-key build-key-pass build-key-pkcs12 build-key-server build-req build-req-pass clean-all inherit-inter list-crl pkitool revoke-full sign-req whichopensslcnf

Dentro deste diretório 2.0 estão todos os shell scripts que falei. Dentro dele existe um arquivo chamado vars e faremos uma configuração nele antes de gerarmos os certificados. Mudaremos as variáveis abaixo do arquivo vars.

export KEY_COUNTRY=”US”
export KEY_PROVINCE=”CA”
export KEY_CITY=”SanFrancisco”
export KEY_ORG=”Fort-Funston”
export KEY_EMAIL=”me@myhost.mydomain”
export KEY_EMAIL=mail@host.domain
export KEY_CN=changeme
export KEY_NAME=changeme
export KEY_OU=changeme

Mudaremos o bloco acima para o nosso exemplo:

export KEY_COUNTRY=”BR”
export KEY_PROVINCE=”RJ”
export KEY_CITY=”Araruama”
export KEY_ORG=”BSDInfo”
export KEY_EMAIL=”ti@bsdinfo.com.br”
export KEY_CN=vpnsrv
export KEY_NAME=vpnsrv
export KEY_OU=TI

Após a configuração do arquivo vars com os dados da criação dos nossos certificados, precisamos inicializar a estrutura que acomodará os certificados que os scripts criarão. Executaremos os seguintes passos:

# cd /usr/local/etc/openvpn/2.0
# bash
# source vars
NOTE: If you run ./clean-all, I will be doing a rm -rf on /usr/local/etc/openvpn/2.0/keys

Com os comandos acima armazenaremos os valores das variáveis que configuramos, em memória, para que os scripts possam usar. Importante executar o bash antes de executar qualquer coisa senão os scripts não funcionarão.

O próximo procedimento só deve ser feito apenas uma vez porque este irá criar a estrutura de controle dos certificados e chaves. Se for feito após a criação de qualquer certificado, todos quem foram criados serão apagados e o controle iniciará do zero.

# ./clean-all

Após o comando acima será criado o diretório /usr/local/etc/openvpn/2.0/keys com os arquivos: index.txt e serial que serão usados no controle da criação dos certificados.

Vamos agora criar Diffie-Hellman do nosso servidor de VPN:

# cd /usr/local/etc/openvpn/2.0
# ./build-dh
Generating DH parameters, 1024 bit long safe prime, generator 2
This is going to take a long time
…..+…………………..++*++*++*

A configuração é um pouco trabalhosa mas não é nenhum bicho de 7 cabeças. Após tudo funcionando, configurar outros servidores será muito simples. A única coisa que poderá deixar complexa a sua configuração é quando existirem muitas redes atrás dos servidores e elas precisarem ser acessadas de todos os lugares.

Agora criaremos o certificado da CA do nosso servidor. Muito cuidado com ele porque é o segredo da segurança da nossa VPN. Qualquer certificado assinado por ele será autorizado à conectar em nossa VPN. Esse é o principal motivo de não se usar certificados de CAs conhecidas. Necessitamos de criar nossa própria CA.

# ./build-ca
Generating a 1024 bit RSA private key
………….++++++
……………++++++
writing new private key to ‘ca.key’
—–
You are about to be asked to enter information that will be incorporated
into your certificate request.
What you are about to enter is what is called a Distinguished Name or a DN.
There are quite a few fields but you can leave some blank
For some fields there will be a default value,
If you enter ‘.’, the field will be left blank.
—–
Country Name (2 letter code) [BR]:
State or Province Name (full name) [RJ]:
Locality Name (eg, city) [Araruama]:
Organization Name (eg, company) [BSDInfo]:
Organizational Unit Name (eg, section) [TI]:
Common Name (eg, your name or your server’s hostname) [vpnsrv]:BSDInfo – CA
Name [vpnsrv]:
Email Address [ti@bsdinfo.com.br]:

Vamos dar uma olhada agora no nosso diretório de keys?

# ls -l /usr/local/etc/openvpn/2.0/keys/
total 16
-rw-r–r– 1 root wheel 1334 May 28 01:29 ca.crt
-rw——- 1 root wheel   887 May 28 01:29 ca.key
-rw-r–r– 1 root wheel   245 May 28 01:24 dh1024.pem
-rw-r–r– 1 root wheel     0 May 28 01:11 index.txt
-rw-r–r– 1 root wheel     3 May 28 01:11 serial

Agora já temos o certificado da CA (ca.crt) que usaremos para assinar o certificado do nosso servidor da VPN e dos outros servidores clientes.

Vamos agora criar nosso primeiro certificado do servidor das VPNs:

# cd /usr/local/etc/openvpn/2.0/
# ./build-key-server vpnsrv
Generating a 1024 bit RSA private key
……………..++++++
…….++++++
writing new private key to ‘vpnsrv.key’
—–
You are about to be asked to enter information that will be incorporated
into your certificate request.
What you are about to enter is what is called a Distinguished Name or a DN.
There are quite a few fields but you can leave some blank
For some fields there will be a default value,
If you enter ‘.’, the field will be left blank.
—–
Country Name (2 letter code) [BR]:
State or Province Name (full name) [RJ]:
Locality Name (eg, city) [Araruama]:
Organization Name (eg, company) [BSDInfo]:
Organizational Unit Name (eg, section) [TI]:
Common Name (eg, your name or your server’s hostname) [vpnsrv]:
Name [vpnsrv]:
Email Address [ti@bsdinfo.com.br]:
Please enter the following ‘extra’ attributes
to be sent with your certificate request
A challenge password []:
An optional company name []:
Using configuration from /usr/local/etc/openvpn/2.0/openssl-0.9.8.cnf
Check that the request matches the signature
Signature ok
The Subject’s Distinguished Name is as follows
countryName           :PRINTABLE:’BR’
stateOrProvinceName   :PRINTABLE:’RJ’
localityName          :PRINTABLE:’Araruama’
organizationName      :PRINTABLE:’BSDInfo’
organizationalUnitName:PRINTABLE:’TI’
commonName            :PRINTABLE:’vpnsrv’
name                  :PRINTABLE:’vpnsrv’
emailAddress          :IA5STRING:’ti@bsdinfo.com.br’
Certificate is to be certified until May 26 05:20:25 2022 GMT (3650 days)
Sign the certificate? [y/n]:y
1 out of 1 certificate requests certified, commit? [y/n]y
Write out database with 1 new entries
Data Base Updated

Aproveitando que estamos criando os certificados, vamos agora criar os certificados das VPNs cliente. Primeiro a da BSDInfo – Saquarema:

# ./build-key vpnsaq
Generating a 1024 bit RSA private key
..++++++
…………++++++
writing new private key to ‘vpnsaq.key’
—–
You are about to be asked to enter information that will be incorporated
into your certificate request.
What you are about to enter is what is called a Distinguished Name or a DN.
There are quite a few fields but you can leave some blank
For some fields there will be a default value,
If you enter ‘.’, the field will be left blank.
—–
Country Name (2 letter code) [BR]:
State or Province Name (full name) [RJ]:
Locality Name (eg, city) [Araruama]:
Organization Name (eg, company) [BSDInfo]:
Organizational Unit Name (eg, section) [TI]:
Common Name (eg, your name or your server’s hostname) [vpnsaq]:
Name [vpnsrv]:vpnsaq
Email Address [ti@bsdinfo.com.br]:
Please enter the following ‘extra’ attributes
to be sent with your certificate request
A challenge password []:
An optional company name []:
Using configuration from /usr/local/etc/openvpn/2.0/openssl-0.9.8.cnf
Check that the request matches the signature
Signature ok
The Subject’s Distinguished Name is as follows
countryName           :PRINTABLE:’BR’
stateOrProvinceName   :PRINTABLE:’RJ’
localityName          :PRINTABLE:’Araruama’
organizationName      :PRINTABLE:’BSDInfo’
organizationalUnitName:PRINTABLE:’TI’
commonName            :PRINTABLE:’vpnsaq’
name                  :PRINTABLE:’vpnsaq’
emailAddress          :IA5STRING:’ti@bsdinfo.com.br’
Certificate is to be certified until May 26 06:22:01 2022 GMT (3650 days)
Sign the certificate? [y/n]:y
1 out of 1 certificate requests certified, commit? [y/n]y
Write out database with 1 new entries
Data Base Update

Agora o certificado e chave da BSDInfo – São Pedro:

# ./build-key vpnspa
Generating a 1024 bit RSA private key
….++++++
………………………………………………………………………………..++++++
writing new private key to ‘vpnspa.key’
—–
You are about to be asked to enter information that will be incorporated
into your certificate request.
What you are about to enter is what is called a Distinguished Name or a DN.
There are quite a few fields but you can leave some blank
For some fields there will be a default value,
If you enter ‘.’, the field will be left blank.
—–
Country Name (2 letter code) [BR]:
State or Province Name (full name) [RJ]:
Locality Name (eg, city) [Araruama]:
Organization Name (eg, company) [BSDInfo]:
Organizational Unit Name (eg, section) [TI]:
Common Name (eg, your name or your server’s hostname) [vpnspa]:
Name [vpnsrv]:vpnspa
Email Address [ti@bsdinfo.com.br]:
Please enter the following ‘extra’ attributes
to be sent with your certificate request
A challenge password []:
An optional company name []:
Using configuration from /usr/local/etc/openvpn/2.0/openssl-0.9.8.cnf
Check that the request matches the signature
Signature ok
The Subject’s Distinguished Name is as follows
countryName           :PRINTABLE:’BR’
stateOrProvinceName   :PRINTABLE:’RJ’
localityName          :PRINTABLE:’Araruama’
organizationName      :PRINTABLE:’BSDInfo’
organizationalUnitName:PRINTABLE:’TI’
commonName            :PRINTABLE:’vpnspa’
name                  :PRINTABLE:’vpnspa’
emailAddress          :IA5STRING:’ti@bsdinfo.com.br’
Certificate is to be certified until May 26 06:31:52 2022 GMT (3650 days)
Sign the certificate? [y/n]:y
1 out of 1 certificate requests certified, commit? [y/n]y
Write out database with 1 new entries
Data Base Updated

Vamos dar uma olhada agora nos certificados e chaves que temos:

# ls -l /usr/local/etc/openvpn/2.0/keys/
total 84
-rw-r–r– 1 root wheel 4030 May 28 02:21 01.pem
-rw-r–r– 1 root wheel 3913 May 28 03:23 02.pem
-rw-r–r– 1 root wheel 3913 May 28 03:31 03.pem
-rw-r–r– 1 root wheel 1334 May 28 01:29 ca.crt
-rw——- 1 root wheel   887 May 28 01:29 ca.key
-rw-r–r– 1 root wheel   245 May 28 01:24 dh1024.pem
-rw-r–r– 1 root wheel   360 May 28 03:31 index.txt
-rw-r–r– 1 root wheel    21 May 28 03:31 index.txt.attr
-rw-r–r– 1 root wheel    21 May 28 03:23 index.txt.attr.old
-rw-r–r– 1 root wheel   240 May 28 03:23 index.txt.old
-rw-r–r– 1 root wheel     3 May 28 03:31 serial
-rw-r–r– 1 root wheel     3 May 28 03:23 serial.old
-rw-r–r– 1 root wheel 3913 May 28 03:23 vpnsaq.crt
-rw-r–r– 1 root wheel   708 May 28 03:22 vpnsaq.csr
-rw——- 1 root wheel   891 May 28 03:22 vpnsaq.key
-rw-r–r– 1 root wheel 3913 May 28 03:31 vpnspa.crt
-rw-r–r– 1 root wheel   708 May 28 03:31 vpnspa.csr
-rw——- 1 root wheel   887 May 28 03:31 vpnspa.key
-rw-r–r– 1 root wheel 4030 May 28 02:21 vpnsrv.crt
-rw-r–r– 1 root wheel   708 May 28 02:20 vpnsrv.csr
-rw——- 1 root wheel   887 May 28 02:20 vpnsrv.key

Agora que temos todos os certificados e chaves que iremos utilizar podemos enfim criar o arquivo de configuração do servidor:

# cd /usr/local/etc/openvpn/
# mkdir /var/log/openvpn
# chmod 750 /var/log/openvpn
# mkdir ccd
# openvpn –genkey –secret ta.key
# cat <<EOF>> vpnsrv.conf
port 1190
proto tcp
dev tun
ca /usr/local/etc/openvpn/2.0/keys/ca.crt
cert /usr/local/etc/openvpn/2.0/keys/vpnsrv.crt
key /usr/local/etc/openvpn/2.0/keys/vpnsrv.key
dh /usr/local/etc/openvpn/2.0/keys/dh1024.pem
server 172.16.24.0 255.255.255.0
ifconfig-pool-persist /usr/local/etc/openvpn/ipp.txt
client-config-dir /usr/local/etc/openvpn/ccd
tls-auth /usr/local/etc/openvpn/ta.key 0
keepalive 10 120
comp-lzo
persist-key
persist-tun
log-append /var/log/openvpn/openvpn.log
status /var/log/openvpn/status.log
client-to-client

# Saquarema Network
route 10.200.201.0 255.255.255.255

# Sao Pedro Network
route 10.200.202.0 255.255.255.255
EOF

O parâmetro cliente-to-client é extremamente importante para que as redes dos clientes possam trocar dados entre si. Caso contrário eles só trocarão dados com a rede do servidor da VPN (10.200.200.0/24).

O diretório ccd é usado para armazenarmos as configurações que forçaremos os clientes à usarem. Nós também criamos e usaremos o ta.key para aumentarmos a segurança e evitarmos um DoS na porta 1190/TCP do nosso servidor OpenVPN. Você pode alterar a porta e o protocolo para UDP como bem quiser, desde que configure também nos clientes.

Adicionamos também as rotas paras as redes 10.200.201.0/24 e 10.200.202.0/24. No parâmetro server definimos a rede usada pelas VPNs entre si que será 172.16.24.0/24.

Estamos quase acabando o servidor. Agora precisamos configurar ele para iniciar no boot do sistema:

# cd /usr/local/etc/rc.d
# ln –sf openvpn vpnsrv
# cat <<EOF>> /etc/rc.conf
vpnsrv_enable=”YES”
vpnsrv_if=”tun”
vpnsrv_configfile=”/usr/local/etc/openvpn/vpnsrv.conf”
vpnsrv_dir=”/usr/local/etc/openvpn”
EOF

Agora sim podemos iniciar nosso servidor de VPN:

# service vpnsrv start

Se tudo correr bem teremos o serviço rodando e algo já nos logs:

# cat /var/log/openvpn.log
Mon May 28 06:47:48 2012 OpenVPN 2.2.2 amd64-portbld-freebsd9.0 [SSL] [LZO2] [eurephia] built on May 27 2012
Mon May 28 06:47:48 2012 NOTE: OpenVPN 2.1 requires ‘–script-security 2’ or higher to call user-defined scripts or executables
Mon May 28 06:47:48 2012 Control Channel Authentication: using ‘/usr/local/etc/openvpn/ta.key’ as a OpenVPN static key file
Mon May 28 06:47:48 2012 TUN/TAP device /dev/tun0 opened
Mon May 28 06:47:48 2012 /sbin/ifconfig tun0 172.16.24.1 172.16.24.2 mtu 1500 netmask 255.255.255.255 up
add net 10.200.201.0: gateway 172.16.24.2
add net 10.200.202.0: gateway 172.16.24.2
add net 172.16.24.0: gateway 172.16.24.2
Mon May 28 06:47:48 2012 Listening for incoming TCP connection on [undef]:1190
Mon May 28 06:47:48 2012 TCPv4_SERVER link local (bound): [undef]:1190
Mon May 28 06:47:48 2012 TCPv4_SERVER link remote: [undef]
Mon May 28 06:47:48 2012 Initialization Sequence Completed
Mon May 28 06:47:48 2012 Ipv6 in tun mode is not supported in OpenVPN 2.2

Notaremos uma nova interface de rede que será usada nos túneis das VPNs:

# ifconfig tun0
tun0: flags=8051<UP,POINTOPOINT,RUNNING,MULTICAST> metric 0 mtu 1500
options=80000<LINKSTATE>
inet6 fe80::a00:27ff:fed0:bdc3%tun0 prefixlen 64 scopeid 0x4
inet 172.16.24.1 à 172.16.24.2 netmask 0xffffffff
nd6 options=21<PERFORMNUD,AUTO_LINKLOCAL>
Opened by PID 42385

Agora precisamos finalizar nosso servidor criando os arquivos de configuração para as outras VPNs naquele diretório /usr/local/etc/openvpn/ccd:

# cd /usr/local/etc/openvpn/ccd/
# cat <<EOF>> vpnsaq
ifconfig-push 172.16.24.6 172.16.24.5
iroute 10.200.201.0 255.255.255.0
EOF

O nome do arquivo, vpnsaq, é muito importante e deve ser o mesmo nome que usamos quando criamos o certificado para BSDInfo Saquarema. Reparem no trecho abaixo:

Organization Name (eg, company) [BSDInfo]:
Organizational Unit Name (eg, section) [TI]:
Common Name (eg, your name or your server’s hostname) [vpnsaq]:

Como podem ver mantive o nome vpnsaq no Common Name e esse deve ser o nome do arquivo de configuração porque quando o cliente se conectar no servidor VPN, o mesmo irá checar o Common Name e tentará abrir o arquivo com aquele nome no /usr/local/etc/openvpn/ccd e aí passará o IP e configurações para o cliente da VPN.

O parâmetro “ifconfig-push 172.16.24.6 172.16.24.5” diz ao cliente VPN de Saquarema que ele usará o IP 172.16.24.6 e seu gateway 172.16.24.5.

Já o parâmetro “eyste 10.200.201.0 255.255.255.0” serve para disponibilizar a rede interna de Saquarema para os demais clientes que no caso do nosso exemplo, seria a VPN de São Pedro. Sem esse parâmetro, a rede de São Pedro (10.200.202.0/24) não conseguiria acessar a rede de Saquarema (10.200.201.0/24).

Agora faremos o mesmo para a VPN da BSDInfo São Pedro:

# cd /usr/local/etc/openvpn/ccd/
# cat <<EOF>> vpnspa
ifconfig-push 172.16.24.10 172.16.24.9
iroute 10.200.202.0 255.255.255.0
EOF

Assim terminamos nossa configuração no servidor da nossa VPN. Passaremos para a configuração dos outros 2 servidores que serão os clientes nesse nosso artigo.

Para configurarmos os clientes precisaremos levar alguns arquivos para esses servidores:

BSDInfo Saquarema:

/usr/local/etc/openvpn/ta.key
/usr/local/etc/openvpn/2.0/keys/ca.crt
/usr/local/etc/openvpn/2.0/keys/vpnsaq.crt
/usr/local/etc/openvpn/2.0/eys/vpnsaq.key

BSDInfo São Pedro:

/usr/local/etc/openvpn/ta.key
/usr/local/etc/openvpn/2.0/eys/ca.crt
/usr/local/etc/openvpn/2.0/eys/vpnspa.crt
/usr/local/etc/openvpn/2.0/eys/vpnspa.key

No servidor de VPN da BSDInfo Saquarema faremos a instalação do OpenVPN conforme mostrado no início do nosso artigo. Criaremos o diretório /usr/local/etc/openvpn e o /var/log/openvpn. Não precisaremos mexer com a estrutura dos certificados e chaves, uma vez que já fizemos esse trabalho no servidor que atenderá as conexões das VPNs.

Colocaremos os arquivos de certificados e chaves, que trouxemos do servidor, em /usr/local/etc/openvpn. Após isso criaremos nosso arquivo de configuração assim:

# cd /usr/local/etc/openvpn/
# cat <<EOF>> vpnsaq.conf
client
dev tun
proto tcp
remote 169.169.169.1 1190
ns-cert-type server
nobind
persist-key
persist-tun
ca /usr/local/etc/openvpn/ca.crt
cert /usr/local/etc/openvpn/vpnsaq.crt
key /usr/local/etc/openvpn/vpnsaq.key
tls-auth /usr/local/etc/openvpn/ta.key 1
comp-lzo
log-append /var/log/openvpn/openvpn.log
status /var/log/openvpn/status.log

# Araruama Network
route 10.200.200.0 255.255.255.0

# Sao Pedro Network
route 10.200.202.0 255.255.255.0
EOF

Após criarmos esse arquivo de configuração teremos os seguintes arquivos:

# ls -l /usr/local/etc/openvpn/
total 20
-rw-r–r– 1 root wheel 1334 May 28 08:46 ca.crt
-rw——- 1 root wheel   636 May 28 08:46 ta.key
-rw-r–r– 1 root wheel   337 May 28 08:47 vpnsaq.conf
-rw-r–r– 1 root wheel 3913 May 28 08:46 vpnsaq.crt
-rw——- 1 root wheel   891 May 28 08:46 vpnsaq.key

Para finalizarmos colocando o OpenVPN na inicialização do sistema:

# cd /usr/local/etc/rc.d
# ln –sf openvpn vpnsaq
# cat <<EOF>> /etc/rc.conf
vpnsaq_enable=”YES”
vpnsaq_if=”tun”
vpnsaq_configfile=”/usr/local/etc/openvpn/vpnsaq.conf”
vpnsaq_dir=”/usr/local/etc/openvpn”
EOF

Para finalizar nosso último cliente da VPN, usaremos os mesmos procedimentos citados no BSDInfo Saquarema mas alterando um pouco a conf e usando os certificados e chaves corretos:

# cd /usr/local/etc/openvpn/
# cat <<EOF>> vpnspa.conf
client
dev tun
proto tcp
remote 169.169.169.1 1190
ns-cert-type server
nobind
persist-key
persist-tun
ca /usr/local/etc/openvpn/ca.crt
cert /usr/local/etc/openvpn/vpnspa.crt
key /usr/local/etc/openvpn/vpnspa.key
tls-auth /usr/local/etc/openvpn/ta.key 1
comp-lzo
log-append /var/log/openvpn/openvpn.log
status /var/log/openvpn/status.log

# Araruama Network
route 10.200.200.0 255.255.255.0

# Saquarema Network
route 10.200.201.0 255.255.255.0
EOF

No final teremos os seguintes arquivos em /usr/local/etc/openvpn/:

# ls -l /usr/local/etc/openvpn/
total 20
-rw-r–r– 1 root wheel 1334 May 28 08:46 ca.crt
-rw——- 1 root wheel   636 May 28 08:46 ta.key
-rw-r–r– 1 root wheel   337 May 28 08:47 vpnspa.conf
-rw-r–r– 1 root wheel 3913 May 28 08:46 vpnspa.crt
-rw——- 1 root wheel   891 May 28 08:46 vpnspa.key

Finalizando o artigo com a configuração para a inicialização dessa VPN:

# cd /usr/local/etc/rc.d
# ln -sf openvpn vpnspa
# cat <<EOF>> /etc/rc.conf
vpnspa_enable=”YES”
vpnspa_if=”tun”
vpnspa_configfile=”/usr/local/etc/openvpn/vpnspa.conf”
vpnspa_dir=”/usr/local/etc/openvpn”
EOF

Qualquer problema sempre consultem os logs gerados em /var/log/openvpn, afinal é para isso que os logs servem. Para nos auxiliar em problemas, informações e gerar estatísticas.

Mais informações sobre OpenVPN podem ser consultadas aqui:

Autor: Marcelo Gondim gondim em bsdinfo.com.br

Data: 29/05/2012

Este artigo é livre para ser distribuído, alterado e melhorado desde que respeitando meus créditos e os créditos de todo aquele que vier à contribuir com este documento.

FreeBSD – compatibilidade binária com Linux

Posted by gondim | Posted in FreeBSD, Software Livre, Tecnologia | Posted on 07-06-2012

Tags:compatibilidade binária, emulação

2

FreeBSD possui o que chamamos de compatibilidade binária com Linux. Veja bem não é emulação! Não estamos falando de um Wine da vida. Tanto FreeBSD quanto Linux executam binários em formato ELF (Executable and Linking Format) e a diferença entre um e outro é mínima. Com algumas configurações veremos que binários Linux podem rodar em FreeBSD e a maior parte deles roda com uma performance melhor no FreeBSD que no próprio Linux. Existem algumas exceções mas são poucas onde não se conseguiria rodar um binário ELF Linux. Usaremos para os nossos testes um FreeBSD 9 32 bits rodando um programa chamado Midnight Commander (mc) que peguei de um Ubuntu Lucid 32 bits. Eu sei, eu sei que existe no ports o Midnight Commander mas o objetivo aqui é ver um binário linux rodando no FreeBSD. 🙂

Vamos começar nossos testes carregando o módulo de compatibilidade binária:

# kldload linux
# kldstat
Id Refs Address            Size     Name
1    6 0xffffffff80200000 11cd9b0 kernel
2    1 0xffffffff81412000 1e17c    linux.ko

Acima carregamos o módulo e podemos observar o linux.ko carregado. Para que isso fique sendo carregado sempre após o boot, adicione a linha abaixo em seu /etc/rc.conf:

linux_enable=”YES”

Também vamos precisar de umas bibliotecas e outros programas utilizados em sistemas GNU/Linux para compor um ambiente necessário de funcionamento e por isso vamos instalar um port específico para isso:

# cd /usr/ports/emulators/linux_base-f10
# make install distclean

Reparem que o port está em “emulators” mas não se trata de emulação. Contudo vamos precisar informar ao FreeBSD que aquele binário é um ELF do tipo Linux para que ele possa lê-lo adequadamente. A maneira de se fazer isso é através de uma marcação no binário. Veja bem a marcação é feita apenas no binário e não nas bibliotecas que este utiliza.

Após a instalação do port acima teremos essa estrutura criada:

# ls -l /compat/linux/
total 48
drwxr-xr-x   2 root wheel 1024 Jun 5 10:47 bin
drwxr-xr-x 17 root wheel 1024 Jun 5 10:48 etc
drwxr-xr-x   6 root wheel 2560 Jun 5 10:47 lib
drwxr-xr-x   2 root wheel   512 Jun 5 10:47 mnt
drwxr-xr-x   2 root wheel   512 Jun 5 10:47 opt
drwxr-xr-x   2 root wheel   512 Jun 5 10:47 proc
drwxr-xr-x   2 root wheel 1024 Jun 5 10:47 sbin
drwxr-xr-x   2 root wheel   512 Jun 5 10:47 selinux
drwxr-xr-x   2 root wheel   512 Jun 5 10:47 srv
drwxr-xr-x   2 root wheel   512 Jun 5 10:47 sys
drwxr-xr-x 13 root wheel   512 Jun 5 10:48 usr
drwxr-xr-x 14 root wheel   512 Jun 5 10:48 var

Precisamos adicionar algumas configurações para evitarmos problemas com programas linux que usem shared memory e proc. Façamos o seguinte:

1º Adicione a linha abaixo em /etc/devfs.conf:

link /tmp shm

2º Adicione a linha abaixo em /etc/fstab:

none /compat/linux/proc linprocfs rw 0 0

Reboot o sistema e começaremos com o Midnight Commander.

No Ubuntu fiz o seguinte comando para vermos todas as libs necessárias para a execução do nosso programa:

# ldd /usr/bin/mc
linux-gate.so.1 => (0x0018e000)
libgpm.so.2 => /usr/lib/libgpm.so.2 (0x0045b000)
libslang.so.2 => /lib/libslang.so.2 (0x0018f000)
libglib-2.0.so.0 => /lib/libglib-2.0.so.0 (0x0073d000)
libc.so.6 => /lib/tls/i686/cmov/libc.so.6 (0x00289000)
libdl.so.2 => /lib/tls/i686/cmov/libdl.so.2 (0x00508000)
libm.so.6 => /lib/tls/i686/cmov/libm.so.6 (0x00110000)
libpcre.so.3 => /lib/libpcre.so.3 (0x00c1d000)
/lib/ld-linux.so.2 (0x005f9000)

Nem só de libs viverá um programa mas sim de todos os arquivos necessários para a sua perfeita execução. 🙂 Então vamos copiar o nosso /usr/bin/mc para o nosso FreeBSD e colocá-lo em /compat/linux/usr/bin/.

Reparem que toda a estrutura que o programa usará ficará embaixo de /compat/linux como se ele fosse a raiz para os binários que executaremos.

Antes de mais nada vamos precisar dizer ao FreeBSD que esse binário se trata de um binário ELF Linux e para isso vamos fazer apenas o seguinte:

# brandelf -t Linux /compat/linux/usr/bin/mc

Vou tentar rodar /compat/linux/mc e ver que erros pegarei:

# /compat/linux/usr/bin/mc
/compat/linux/usr/bin/mc: error while loading shared libraries: libgpm.so.2: cannot open shared object file: No such file or directory

Opa! Ele reclamou da libgpm.so.2 que na verdade é um link simbólico para libgpm.so.2.0.0. Vamos então copiar do Ubuntu a lib /usr/lib/libgpm.so.2.0.0 para o FreeBSD em /compat/linux/usr/lib e executar:

# cd /compat/linux/usr/lib
# ln -sf libgpm.so.2.0.0 libgpm.so.2

Depois disso vamos rodá-lo novamente e veremos algo assim:

Tem algo errado ainda porque a tela deveria estar com fundo azul e os gráficos certos. Bem, vamos sair com F10 e ver se aparece algum erro:

# /compat/linux/usr/bin/mc
Warning: file /etc/mc/extfs/extfs.ini not found
Warning: file /etc/mc/extfs/sfs.ini not found
Warning: file /etc/mc/mc.charsets not found
Warning: file /usr/share/mc/mc.charsets not found

Ummm podemos deduzir então que faltam algumas coisas como o /etc/mc e o /usr/share/mc que estão lá no Ubuntu. Para resolver isso pegaremos o conteúdo de cada diretório e colocaremos eles em /compat/linux/etc/mc e /compat/linux/usr/share/mc.

Feito isso agora sim rodaremos o nosso /compat/linux/usr/bin/mc e veremos a tela certa e sem erros:

Bem é isso pessoal, para mais informações vocês podem consultar o Handbook aqui.

Para fazer o mesmo em um FreeBSD 64 bits existem algumas coisas que precisam ser feitas. Aqui está uma página, embora antiga, boa para consultar sobre rodando binários 32 bits do Linux em FreeBSD 64 bits.

Be happy!!

MeetBSD California 2012 – 3 e 4 de novembro

Posted by gondim | Posted in FreeBSD, Tecnologia | Posted on 01-06-2012

Tags:conference, conferência, meetbsd

0

O pessoal do MeetBSD, em sua terceira bienal, convida à todos para participarem desse evento que ocorrerá na California no campus Yahoo! em Sunnyvale.
O evento ocorrerá em um sábado e domingo dias 03/11 e 04/11. Quem se registrar até o dia 30/06 pagará US$10,00, após essa data o registro custará US$75,00. Como ainda está distante, quem tiver interesse e condições de ir ainda dá tempo para se programar.

Abaixo mais informações para quem se interessar:

To keep up with information about MeetBSD California 2012, follow us on Twitter http://twitter.com/#!/MeetBSDCA, “Like” us on Facebook at
http://www.facebook.com/MeetbsdCalifornia, follow us on Google Plus at http://plus.google.com/109740340769158691256, or keep visiting http://www.meetbsd.com.

Conference registration link: https://www.meetbsd.com/registration
Travel/hotel information: https://www.meetbsd.com/travel
See the announcement here:
http://www.ixsystems.com/resources/ix/news/ixsystems-announces-meetbsd-california-2012.html

Por que pessoas usam FreeBSD?

Posted by gondim | Posted in Dicas, FreeBSD | Posted on 31-05-2012

7

Eu recentemente perguntei para alguns usuários FreeBSD por que eles estão usando o sistema e essas foram as respostas que recebi:

A Comunidade:

FreeBSD é orientado pela Comunidade e mesmo tendo muitos usuários corporativos e contribuidores, eles não afetam a forma como o FreeBSD é conduzido pela Comunidade. FreeBSD tem listas de discussões ativas, fóruns e canais de IRC onde usuários experientes e desenvolvedores estão sempre dispostos a ajudar os menos experientes.

Abaixo a lista atual das listas de discussões. Acharam pouco?

Lista de discussão brasileira: http://www.fug.com.br

freebsd-advocacy	FreeBSD Evangelism
freebsd-announce	Important events and project milestones
freebsd-arch	Architecture and design discussions
freebsd-bugbusters	Discussions pertaining to the maintenance of the FreeBSD problem report database and related tools
freebsd-bugs	Bug reports
freebsd-chat	Non-technical items related to the FreeBSD community
freebsd-chromium	FreeBSD-specific Chromium issues
freebsd-current	Discussion concerning the use of FreeBSD-CURRENT
freebsd-isp	Issues for Internet Service Providers using FreeBSD
freebsd-jobs	FreeBSD employment and consulting opportunities
freebsd-questions	User questions and technical support
freebsd-security-notifications	Security notifications
freebsd-stable	Discussion concerning the use of FreeBSD-STABLE
freebsd-test	Where to send your test messages instead of one of the actual lists

freebsd-acpi	ACPI and power management development
freebsd-afs	Porting AFS to FreeBSD
freebsd-aic7xxx	Developing drivers for the Adaptec® AIC 7xxx
freebsd-amd64	Porting FreeBSD to AMD64 systems
freebsd-apache	Discussion about Apache related ports
freebsd-arm	Porting FreeBSD to ARM® processors
freebsd-atm	Using ATM networking with FreeBSD
freebsd-binup	Design and development of the binary update system
freebsd-bluetooth	Using Bluetooth® technology in FreeBSD
freebsd-cluster	Using FreeBSD in a clustered environment
freebsd-cvsweb	CVSweb maintenance
freebsd-database	Discussing database use and development under FreeBSD
freebsd-desktop	Using and improving FreeBSD on the desktop
freebsd-doc	Creating FreeBSD related documents
freebsd-drivers	Writing device drivers for FreeBSD
freebsd-eclipse	FreeBSD users of Eclipse IDE, tools, rich client applications and ports.
freebsd-embedded	Using FreeBSD in embedded applications
freebsd-eol	Peer support of FreeBSD-related software that is no longer supported by the FreeBSD project.
freebsd-emulation	Emulation of other systems such as Linux/MS-DOS®/Windows®
freebsd-firewire	FreeBSD FireWire® (iLink, IEEE 1394) technical discussion
freebsd-fs	File systems
freebsd-gecko	Gecko Rendering Engine issues
freebsd-geom	GEOM-specific discussions and implementations
freebsd-gnome	Porting GNOME and GNOME applications
freebsd-hackers	General technical discussion
freebsd-hardware	General discussion of hardware for running FreeBSD
freebsd-i18n	FreeBSD Internationalization
freebsd-ia32	FreeBSD on the IA-32 (Intel® x86) platform
freebsd-ia64	Porting FreeBSD to Intel’s upcoming IA64 systems
freebsd-ipfw	Technical discussion concerning the redesign of the IP firewall code
freebsd-isdn	ISDN developers
freebsd-jail	Discussion about the jail(8) facility
freebsd-java	Java™ developers and people porting JDK™s to FreeBSD
freebsd-kde	Porting KDE and KDE applications
freebsd-lfs	Porting LFS to FreeBSD
freebsd-mips	Porting FreeBSD to MIPS®
freebsd-mobile	Discussions about mobile computing
freebsd-mono	Mono and C# applications on FreeBSD
freebsd-mozilla	Porting Mozilla to FreeBSD
freebsd-multimedia	Multimedia applications
freebsd-new-bus	Technical discussions about bus architecture
freebsd-net	Networking discussion and TCP/IP source code
freebsd-office	Office applications on FreeBSD
freebsd-performance	Performance tuning questions for high performance/load installations
freebsd-perl	Maintenance of a number of Perl-related ports
freebsd-pf	Discussion and questions about the packet filter firewall system
freebsd-platforms	Concerning ports to non Intel architecture platforms
freebsd-ports	Discussion of the Ports Collection
freebsd-ports-announce	Important news and instructions about the Ports Collection
freebsd-ports-bugs	Discussion of the ports bugs/PRs
freebsd-ppc	Porting FreeBSD to the PowerPC®
freebsd-proliant	Technical discussion of FreeBSD on HP ProLiant server platforms
freebsd-python	FreeBSD-specific Python issues
freebsd-rc	Discussion related to the `rc.d` system and its development
freebsd-realtime	Development of realtime extensions to FreeBSD
freebsd-ruby	FreeBSD-specific Ruby discussions
freebsd-scsi	The SCSI subsystem
freebsd-security	Security issues affecting FreeBSD
freebsd-small	Using FreeBSD in embedded applications (obsolete; use freebsd-embedded instead)
freebsd-sparc64	Porting FreeBSD to SPARC® based systems
freebsd-standards	FreeBSD’s conformance to the C99 and the POSIX® standards
freebsd-sysinstall	sysinstall(8) development
freebsd-threads	Threading in FreeBSD
freebsd-tilera	Porting FreeBSD to the Tilera family of CPUs
freebsd-tokenring	Support Token Ring in FreeBSD
freebsd-toolchain	Maintenance of FreeBSD’s integrated toolchain
freebsd-usb	Discussing FreeBSD support for USB
freebsd-virtualization	Discussion of various virtualization techniques supported by FreeBSD
freebsd-vuxml	Discussion on VuXML infrastructure
freebsd-x11	Maintenance and support of X11 on FreeBSD
freebsd-xen	Discussion of the FreeBSD port to Xen™ — implementation and usage
freebsd-xfce	XFCE for FreeBSD — porting and maintaining
freebsd-zope	Zope for FreeBSD — porting and maintaining

freebsd-hubs	People running mirror sites (infrastructural support)
freebsd-user-groups	User group coordination
freebsd-vendors	Vendors pre-release coordination
freebsd-wip-status	FreeBSD Work-In-Progress Status
freebsd-wireless	Discussions of 802.11 stack, tools, device driver development
freebsd-www	Maintainers of www.FreeBSD.org

cvs-all	`/usr/(CVSROOT\|doc\|ports)`	All changes to any place in the tree (superset of other CVS commit lists)
cvs-doc	`/usr/(doc\|www)`	All changes to the doc and www trees
cvs-ports	`/usr/ports`	All changes to the ports tree
cvs-projects	`/usr/projects`	All changes to the projects tree
cvs-src	`/usr/src`	All changes to the src tree (generated by the svn-to-cvs importer commits)
svn-src-all	`/usr/src`	All changes to the Subversion repository (except for `user` and `projects`)
svn-src-head	`/usr/src`	All changes to the “head” branch of the Subversion repository (the FreeBSD-CURRENT branch)
svn-src-projects	`/usr/projects`	All changes to the `projects` area of the src Subversion repository
svn-src-release	`/usr/src`	All changes to the `releases` area of the src Subversion repository
svn-src-releng	`/usr/src`	All changes to the `releng` branches of the src Subversion repository (the security / release engineering branches)
svn-src-stable	`/usr/src`	All changes to the all stable branches of the src Subversion repository
svn-src-stable-6	`/usr/src`	All changes to the `stable/6` branch of the src Subversion repository
svn-src-stable-7	`/usr/src`	All changes to the `stable/7` branch of the src Subversion repository
svn-src-stable-8	`/usr/src`	All changes to the `stable/8` branch of the src Subversion repository
svn-src-stable-9	`/usr/src`	All changes to the `stable/9` branch of the src Subversion repository
svn-src-stable-other	`/usr/src`	All changes to the older `stable` branches of the src Subversion repository
svn-src-svnadmin	`/usr/src`	All changes to the administrative scripts, hooks, and other configuration data of the src Subversion repository
svn-src-user	`/usr/src`	All changes to the experimental `user` area of the src Subversion repository
svn-src-vendor	`/usr/src`	All changes to the vendor work area of the src Subversion repository

Para saber mais sobre as listas acima e como assiná-las acesse aqui.

Estabilidade:

Estabilidade significa muitas coisas diferentes. FreeBSD muito raramente falha (e quando isso acontece, geralmente é devido à falhas de hardware), mas ao mesmo tempo que isso era vanglorioso umas décadas atrás, agora é uma característica esperada para qualquer sistema operacional.

Estabilidade no FreeBSD significa mais do que isso. Isso significa que atualizar o sistema não necessita de atualizar o usuário. Interfaces de configuração mudam ao longo do tempo, mas apenas quando há uma boa razão. Se você aprendeu a usar o FreeBSD em 2000, então a maioria de seu conhecimento ainda seria relevante.

Compatibilidade com versões anteriores é muito importante para a equipe do FreeBSD, e qualquer release de uma major release espera-se que seja capaz de executar qualquer código – incluindo os módulos do kernel – que funcionaram em uma versão anterior.

A estabilidade no FreeBSD é uma coisa realmente relevante e na maior parte dos problemas que já tive usando FreeBSD, foram causados por hardwares que apresentaram problemas. Temos que lembrar que para servidores existem hardwares adequados e que usar equipamentos para desktops não é nada bom para a estabilidade.

Configuração Simples:

O serviço de inicialização do FreeBSD é muito simples. Cada serviço, se for parte da base do sistema ou instalado de um port, vem com um script que é responsável por iniciar e parar este e freqüêntemente alguma outra opção. O arquivo /etc/rc.conf contém uma lista de variáveis para habilitar e configurar serviços. Quer habilitar ssh? Apenas adicione sshd_enable=”YES” para o seu arquivo rc.conf. Este sistema torna mais fácil de ver tudo que será iniciado no boot.

O sistema RCng que lê este arquivo, entende as dependências entre os serviços e então pode automaticamente rodar eles em paralelo ou esperar até que um finalize antes de iniciar as coisas que precise. Você obtem todos os benefícios de um sistema moderno de configuração, sem uma interface complexa.

Ports:

A árvore do ports contém uma enorme coleção de software de terceiros, incluindo as versões mais antigas de algumas coisas onde a userbase é dividida sobre os benefícios da atualização e um monte de programas de nicho. As probabilidades são, qualquer coisa que você queira executar, que funcione em FreeBSD, estará lá.

Ao contrário de alguns outros sistemas, FreeBSD mantém uma divisão clara entre o sistema base e o ports e pacotes de terceiros. Todos os softwares de terceiros vão em /usr/local, então se você quiser mudar o propósito de uma máquina basta simplesmente deletar todos os pacotes instalados e depois instalar os pacotes que deseja.

A próxima ferramenta pkg-ng tornará o trabalho com pacotes binários ainda mais fácil , embora instalação de fontes será ainda suportada para pessoas que quiserem um nível de configurabilidade.

Segurança:

Segurança é vital para qualquer máquina conectada em rede. FreeBSD fornece um número de ferramentas para assegurar que você possa manter um sistema seguro, tais como:

Jails, permitindo você executar aplicações – ou sistemas inteiros – em uma sandbox que não pode acessar o resto do sistema. Com ferramentas como ezjail e ZFS você pode instantaneamente criar uma nova jail com o clone de um sistema existente, usando uma pequena quantidade de espaço em disco, e executar dentro dela código não confiável.
Mandatory Access Control, do projeto TrustedBSD, permitindo você configurar políticas de controle de acesso para todos os recursos do sistema operacional.
Capsicum, à partir do FreeBSD 9, permite aos desenvolvedores facilmente implementarem separação de privilégios, reduzindo o impacto de código comprometido.
O sistema VuXML para publicar vulnerabilidades no ports, que integrado com ferramentas como portaudit, de modo que seu e-mail diário de segurança lhe dirá sobre qualquer vulnerabilidade conhecida em softwares instalados do ports
Auditoria de eventos de Segurança, usando o padrão BSM.

E, claro, todas as características padrões que você esperaria de um sistema UNIX moderno, incluindo IPSec, SSH, e assim por diante.

ZFS:

Cheap snapshots, clones, end-to-end checksums, deduplication, compression, e sem a necessidade de decidir o tamanho das partições na instalação. O que não está gostando? Use o ZFS por poucos dias e volte para um doloroso gerenciador de volume mais tradicional. Se você quiser testar alguma coisa com ZFS então apenas crie um snapshot e faça um roll back se o que você fez não funcionar.

Se você está usando jails, então ZFS permitirá você clonar uma jail em menos de um segundo independente de quão grande seja a jail.

GEOM:

Mesmo sem o ZFS, FreeBSD vem com rico sistema de armazenamento. Camadas GEOM provedores e consumidores de forma arbitrária, permitindo você usar duas máquinas em rede para armazenamento de alta disponibilidade, use o nível de RAID da sua escolha ou adicione características como compressão ou encriptação.

Working Sound:

FreeBSD 4 introduziu no kernel o sound mixing, então multiplas aplicações podem tocar som ao mesmo tempo, mesmo quando usando placas de som baratas sem suporte à mixagem por hardware. FreeBSD 5 automaticamente alocou novos canais para aplicações, sem qualquer configuração.

Meu sistema, do jeito que eu quero:

FreeBSD dá à você um sistema UNIX-like fácil de usar e trabalhar. O sistema base pode facilmente ser extendido. Se você quiser rodar KDE ou GNOME, você precisa instalar o meta pacote da versão que você preferir. Se você quiser um servidor sem monitor, teclado e mouse, este é muito fácil de instalar as ferramentas que você deseja.

É fácil de instalar o FreeBSD via porta serial e configurar o sistema inteiro de um terminal. É fácil também instalar e usar qualquer ambiente desktop existente. As decisões sobre o tipo de sistema que você quer usar são deixadas pra você mesmo decidir.

O texto acima foi tirado daqui e adicionei algumas coisas.

Novas vulnerabilidades no FreeBSD – OpenSSL e Crypt

Posted by gondim | Posted in FreeBSD, Segurança | Posted on 30-05-2012

Tags:crypt, openssl

1

As vulnerabilidades encontradas não aparecerão no portaudit e por isso deve ser dada uma atenção melhor. Muitos programas utilizam o openssl e o crypt. Se você compilou algum programa estaticamente com essas libs então precisará recompilá-los após aplicar os patches.
======================================================================
FreeBSD-SA-12:01.openssl Security Advisory The FreeBSD Project

Topic: OpenSSL multiple vulnerabilities

Category:       contrib
Module:         openssl
Announced:      2012-05-03
Credits:        Adam Langley, George Kadianakis, Ben Laurie, Ivan Nestlerode, Tavis Ormandy
Affects:        All supported versions of FreeBSD.
Corrected:      2012-05-30 12:01:28 UTC (RELENG_7, 7.4-STABLE)
2012-05-30 12:01:28 UTC (RELENG_7_4, 7.4-RELEASE-p8)
2012-05-30 12:01:28 UTC (RELENG_8, 8.3-STABLE)
2012-05-30 12:01:28 UTC (RELENG_8_3, 8.3-RELEASE-p2)
2012-05-30 12:01:28 UTC (RELENG_8_2, 8.2-RELEASE-p8)
2012-05-30 12:01:28 UTC (RELENG_8_1, 8.1-RELEASE-p10)
2012-05-30 12:01:28 UTC (RELENG_9, 9.0-STABLE)
2012-05-30 12:01:28 UTC (RELENG_9_0, 9.0-RELEASE-p2)
CVE Name:       CVE-2011-4576, CVE-2011-4619, CVE-2011-4109, CVE-2012-0884, CVE-2012-2110

For general information regarding FreeBSD Security Advisories,
including descriptions of the fields above, security branches, and the
following sections, please visit <URL:http://security.FreeBSD.org/>.

0. Revision History

v1.0 2012-05-02 Initial release.
v1.1 2012-05-30 Updated patch to add SGC and BUF_MEM_grow_clean(3) bug
fixes.

I. Background

FreeBSD includes software from the OpenSSL Project. The OpenSSL Project is
a collaborative effort to develop a robust, commercial-grade, full-featured
Open Source toolkit implementing the Secure Sockets Layer (SSL v2/v3)
and Transport Layer Security (TLS v1) protocols as well as a full-strength
general purpose cryptography library.

II. Problem Description

OpenSSL fails to clear the bytes used as block cipher padding in SSL 3.0
records when operating as a client or a server that accept SSL 3.0
handshakes. As a result, in each record, up to 15 bytes of uninitialized
memory may be sent, encrypted, to the SSL peer. This could include
sensitive contents of previously freed memory. [CVE-2011-4576]

OpenSSL support for handshake restarts for server gated cryptography (SGC)
can be used in a denial-of-service attack. [CVE-2011-4619]

If an application uses OpenSSL’s certificate policy checking when
verifying X509 certificates, by enabling the X509_V_FLAG_POLICY_CHECK
flag, a policy check failure can lead to a double-free. [CVE-2011-4109]

A weakness in the OpenSSL PKCS #7 code can be exploited using
Bleichenbacher’s attack on PKCS #1 v1.5 RSA padding also known as the
million message attack (MMA). [CVE-2012-0884]

The asn1_d2i_read_bio() function, used by the d2i_*_bio and d2i_*_fp
functions, in OpenSSL contains multiple integer errors that can cause
memory corruption when parsing encoded ASN.1 data. This error can occur
on systems that parse untrusted ASN.1 data, such as X.509 certificates
or RSA public keys. [CVE-2012-2110]

III. Impact

Sensitive contents of the previously freed memory can be exposed
when communicating with a SSL 3.0 peer. However, FreeBSD OpenSSL
version does not support SSL_MODE_RELEASE_BUFFERS SSL mode and
therefore have a single write buffer per connection. That write buffer
is partially filled with non-sensitive, handshake data at the beginning
of the connection and, thereafter, only records which are longer than
any previously sent record leak any non-encrypted data. This, combined
with the small number of bytes leaked per record, serves to limit to
severity of this issue. [CVE-2011-4576]

Denial of service can be caused in the OpenSSL server application
supporting server gated cryptography by performing multiple handshake
restarts. [CVE-2011-4619]

The double-free, when an application performs X509 certificate policy
checking, can lead to denial of service in that application.
[CVE-2011-4109]

A weakness in the OpenSSL PKCS #7 code can lead to a successful
Bleichenbacher attack. Only users of PKCS #7 decryption operations are
affected. A successful attack needs on average 2

^20

messages. In
practice only automated systems will be affected as humans will not be
willing to process this many messages. SSL/TLS applications are not
affected. [CVE-2012-0884]

The vulnerability in the asn1_d2i_read_bio() OpenSSL function can lead
to a potentially exploitable attack via buffer overflow. The SSL/TLS
code in OpenSSL is not affected by this issue, nor are applications
using the memory based ASN.1 functions. There are no applications in
FreeBSD base system affected by this issue, though some 3rd party
consumers of these functions might be vulnerable when processing
untrusted ASN.1 data. [CVE-2012-2110]

The patch provided with the initial version of this advisory introduced
bug to the Server Gated Cryptography (SGC) handshake code, that could
cause SGC handshake to fail for a legitimate client. The updated patch
also fixes the return error code in the BUF_MEM_grow_clean(3) function in the
buffer size check code introduced by the CVE-2012-2110 fix.

IV. Workaround

No workaround is available.

V. Solution

Perform one of the following:

1) Upgrade your vulnerable system to 7-STABLE, 8-STABLE or 9-STABLE,
or to the RELENG_7_4, RELENG_8_3, RELENG_8_2, RELENG_8_1, RELENG_9_0
security branch dated after the correction date.

2) To update your vulnerable system via a source code patch:

The following patches have been verified to apply to FreeBSD 7.4, 8.3,
8.2, 8.1, and 9.0 systems.

a) Download the relevant patch from the location below, and verify the
detached PGP signature using your PGP utility.

# fetch http://security.FreeBSD.org/patches/SA-12:01/openssl2.patch
# fetch http://security.FreeBSD.org/patches/SA-12:01/openssl2.patch.asc

NOTE: The patch distributed at the time of the original advisory fixed
the security vulnerability, but introduced a bug to the SGC handshake
code that can cause the SGC handshake to fail for a legitimate client.
Systems to which the original patch was applied should be patched with
the following corrective patch, which contains only the additional
changes required to fix the newly-introduced SGC handshake bug. The
updated patch also corrects an error code for an error check introduced
in the original patch.

# fetch http://security.FreeBSD.org/patches/SA-12:01/openssl-sgc-fix.patch
# fetch http://security.FreeBSD.org/patches/SA-12:01/openssl-sgc-fix.patch.asc

b) Execute the following commands as root:

# cd /usr/src
# patch < /path/to/patch

c) Recompile the operating system as described in
<URL: http://www.freebsd.org/handbook/makeworld.html> and reboot the
system.

NOTE: Any third-party applications, including those installed from the
FreeBSD ports collection, which are statically linked to libcrypto(3)
should be recompiled in order to use the corrected code.

3) To update your vulnerable system via a binary patch:

Systems running 7.4-RELEASE, 8.3-RELEASE, 8.2-RELEASE, 8.1-RELEASE or
9.0-RELEASE on the i386 or amd64 platforms can be updated via the
freebsd-update(8) utility:

# freebsd-update fetch
# freebsd-update install

VI. Correction details

The following list contains the revision numbers of each file that was
corrected in FreeBSD.

CVS:

Branch                                                           Revision
Path
– ————————————————————————-
RELENG_7
src/crypto/openssl/crypto/buffer/buffer.c                   1.1.1.4.2.3
src/crypto/openssl/crypto/pkcs7/pk7_doit.c                 1.1.1.13.2.2
src/crypto/openssl/crypto/mem.c                             1.1.1.8.2.2
src/crypto/openssl/crypto/x509v3/pcy_map.c                  1.1.1.1.2.2
src/crypto/openssl/crypto/x509v3/pcy_tree.c                 1.1.1.2.2.2
src/crypto/openssl/crypto/asn1/a_d2i_fp.c                   1.1.1.3.2.1
src/crypto/openssl/ssl/ssl.h                               1.1.1.16.2.3
src/crypto/openssl/ssl/ssl_err.c                           1.1.1.11.2.3
src/crypto/openssl/ssl/s3_enc.c                            1.1.1.13.2.2
src/crypto/openssl/ssl/s3_srvr.c                           1.1.1.17.2.8
src/crypto/openssl/ssl/ssl3.h                               1.1.1.6.2.2
RELENG_7_4
src/UPDATING                                            1.507.2.36.2.10
src/sys/conf/newvers.sh                                  1.72.2.18.2.13
src/crypto/openssl/crypto/buffer/buffer.c               1.1.1.4.2.1.2.2
src/crypto/openssl/crypto/pkcs7/pk7_doit.c             1.1.1.13.2.1.2.1
src/crypto/openssl/crypto/mem.c                         1.1.1.8.2.1.2.1
src/crypto/openssl/crypto/x509v3/pcy_map.c              1.1.1.1.2.1.2.1
src/crypto/openssl/crypto/x509v3/pcy_tree.c             1.1.1.2.2.1.2.1
src/crypto/openssl/crypto/asn1/a_d2i_fp.c                  1.1.1.3.20.1
src/crypto/openssl/ssl/ssl.h                           1.1.1.16.2.2.2.1
src/crypto/openssl/ssl/ssl_err.c                       1.1.1.11.2.2.2.1
src/crypto/openssl/ssl/s3_enc.c                        1.1.1.13.2.1.2.1
src/crypto/openssl/ssl/s3_srvr.c                       1.1.1.17.2.5.2.2
src/crypto/openssl/ssl/ssl3.h                           1.1.1.6.2.1.2.1
RELENG_8
src/crypto/openssl/crypto/buffer/buffer.c                       1.2.2.2
src/crypto/openssl/crypto/pkcs7/pk7_doit.c                1.1.1.13.10.2
src/crypto/openssl/crypto/mem.c                                 1.2.2.1
src/crypto/openssl/crypto/x509v3/pcy_map.c                      1.2.2.1
src/crypto/openssl/crypto/x509v3/pcy_tree.c                     1.2.2.2
src/crypto/openssl/crypto/asn1/a_d2i_fp.c                  1.1.1.3.10.1
src/crypto/openssl/ssl/ssl.h                                    1.2.2.2
src/crypto/openssl/ssl/ssl_err.c                                1.2.2.2
src/crypto/openssl/ssl/s3_enc.c                                 1.2.2.2
src/crypto/openssl/ssl/s3_srvr.c                                1.3.2.6
src/crypto/openssl/ssl/ssl3.h                                   1.2.2.2
RELENG_8_3
src/UPDATING                                             1.632.2.26.2.4
src/sys/conf/newvers.sh                                   1.83.2.15.2.6
src/crypto/openssl/crypto/buffer/buffer.c                      1.2.14.2
src/crypto/openssl/crypto/pkcs7/pk7_doit.c            1.1.1.13.10.1.4.1
src/crypto/openssl/crypto/mem.c                                1.2.14.1
src/crypto/openssl/crypto/x509v3/pcy_map.c                     1.2.14.1
src/crypto/openssl/crypto/x509v3/pcy_tree.c                 1.2.2.1.6.1
src/crypto/openssl/crypto/asn1/a_d2i_fp.c                  1.1.1.3.26.1
src/crypto/openssl/ssl/ssl.h                                1.2.2.1.6.1
src/crypto/openssl/ssl/ssl_err.c                            1.2.2.1.6.1
src/crypto/openssl/ssl/s3_enc.c                             1.2.2.1.4.1
src/crypto/openssl/ssl/s3_srvr.c                            1.3.2.4.2.2
src/crypto/openssl/ssl/ssl3.h                               1.2.2.1.6.1
RELENG_8_2
src/UPDATING                                            1.632.2.19.2.10
src/sys/conf/newvers.sh                                  1.83.2.12.2.13
src/crypto/openssl/crypto/buffer/buffer.c                       1.2.8.2
src/crypto/openssl/crypto/pkcs7/pk7_doit.c            1.1.1.13.10.1.2.1
src/crypto/openssl/crypto/mem.c                                 1.2.8.1
src/crypto/openssl/crypto/x509v3/pcy_map.c                      1.2.8.1
src/crypto/openssl/crypto/x509v3/pcy_tree.c                 1.2.2.1.4.1
src/crypto/openssl/crypto/asn1/a_d2i_fp.c                  1.1.1.3.18.1
src/crypto/openssl/ssl/ssl.h                                1.2.2.1.4.1
src/crypto/openssl/ssl/ssl_err.c                            1.2.2.1.4.1
src/crypto/openssl/ssl/s3_enc.c                             1.2.2.1.2.1
src/crypto/openssl/ssl/s3_srvr.c                            1.3.2.3.2.2
src/crypto/openssl/ssl/ssl3.h                               1.2.2.1.4.1
RELENG_8_1
src/UPDATING                                            1.632.2.14.2.13
src/sys/conf/newvers.sh                                  1.83.2.10.2.14
src/crypto/openssl/crypto/buffer/buffer.c                       1.2.6.2
src/crypto/openssl/crypto/pkcs7/pk7_doit.c                1.1.1.13.16.1
src/crypto/openssl/crypto/mem.c                                 1.2.6.1
src/crypto/openssl/crypto/x509v3/pcy_map.c                      1.2.6.1
src/crypto/openssl/crypto/x509v3/pcy_tree.c                 1.2.2.1.2.1
src/crypto/openssl/crypto/asn1/a_d2i_fp.c                  1.1.1.3.16.1
src/crypto/openssl/ssl/ssl.h                                1.2.2.1.2.1
src/crypto/openssl/ssl/ssl_err.c                            1.2.2.1.2.1
src/crypto/openssl/ssl/s3_enc.c                                 1.2.6.1
src/crypto/openssl/ssl/s3_srvr.c                            1.3.2.2.2.2
src/crypto/openssl/ssl/ssl3.h                               1.2.2.1.2.1
RELENG_9
src/crypto/openssl/crypto/buffer/buffer.c                      1.2.10.2
src/crypto/openssl/crypto/pkcs7/pk7_doit.c                      1.2.2.1
src/crypto/openssl/crypto/mem.c                                1.2.10.1
src/crypto/openssl/crypto/x509v3/pcy_map.c                     1.2.10.1
src/crypto/openssl/crypto/x509v3/pcy_tree.c                     1.3.2.1
src/crypto/openssl/crypto/asn1/a_d2i_fp.c                  1.1.1.3.22.1
src/crypto/openssl/ssl/ssl.h                                    1.3.2.1
src/crypto/openssl/ssl/ssl_err.c                                1.3.2.1
src/crypto/openssl/ssl/s3_enc.c                                 1.3.2.1
src/crypto/openssl/ssl/s3_srvr.c                                1.7.2.2
src/crypto/openssl/ssl/ssl3.h                                   1.3.2.1
RELENG_9_0
src/UPDATING                                              1.702.2.4.2.4
src/sys/conf/newvers.sh                                    1.95.2.4.2.6
src/crypto/openssl/crypto/buffer/buffer.c                      1.2.12.2
src/crypto/openssl/crypto/pkcs7/pk7_doit.c                      1.2.4.1
src/crypto/openssl/crypto/mem.c                                1.2.12.1
src/crypto/openssl/crypto/x509v3/pcy_map.c                     1.2.12.1
src/crypto/openssl/crypto/x509v3/pcy_tree.c                     1.3.4.1
src/crypto/openssl/crypto/asn1/a_d2i_fp.c                  1.1.1.3.24.1
src/crypto/openssl/ssl/ssl.h                                    1.3.4.1
src/crypto/openssl/ssl/ssl_err.c                                1.3.4.1
src/crypto/openssl/ssl/s3_enc.c                                 1.3.4.1
src/crypto/openssl/ssl/s3_srvr.c                                1.7.4.2
src/crypto/openssl/ssl/ssl3.h                                   1.3.4.1
– ————————————————————————-

Subversion:

Branch/path                                                      Revision
– ————————————————————————-
stable/7/                                                         r236304
releng/7.4/                                                       r236304
stable/8/                                                         r236304
releng/8.3/                                                       r236304
releng/8.2/                                                       r236304
releng/8.1/                                                       r236304
stable/9/                                                         r236304
releng/9.0/                                                       r236304
– ————————————————————————-

VII. References

http://www.openssl.org/news/secadv_20120419.txt
http://www.openssl.org/news/secadv_20120312.txt
http://www.openssl.org/news/secadv_20120104.txt
http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2011-4576
http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2011-4619
http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2011-4109
http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2012-0884
http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2012-2110
http://lists.openwall.net/full-disclosure/2012/04/19/4

The latest revision of this advisory is available at
http://security.FreeBSD.org/advisories/FreeBSD-SA-12:01.openssl.asc

======================================================================
FreeBSD-SA-12:02.crypt Security Advisory The FreeBSD Project

Topic: Incorrect crypt() hashing

Category:       core
Module:         libcrypt
Announced:      2012-05-30
Credits:        Rubin Xu, Joseph Bonneau, Donting Yu
Affects:        All supported versions of FreeBSD.
Corrected:      2012-05-30 12:01:28 UTC (RELENG_7, 7.4-STABLE)
2012-05-30 12:01:28 UTC (RELENG_7_4, 7.4-RELEASE-p8)
2012-05-30 12:01:28 UTC (RELENG_8, 8.3-STABLE)
2012-05-30 12:01:28 UTC (RELENG_8_3, 8.3-RELEASE-p2)
2012-05-30 12:01:28 UTC (RELENG_8_2, 8.2-RELEASE-p8)
2012-05-30 12:01:28 UTC (RELENG_8_1, 8.1-RELEASE-p10)
2012-05-30 12:01:28 UTC (RELENG_9, 9.0-STABLE)
2012-05-30 12:01:28 UTC (RELENG_9_0, 9.0-RELEASE-p2)
CVE Name:       CVE-2012-2143

I. Background

The crypt(3) function performs password hashing with additional code added
to deter key search attempts.

II. Problem Description

There is a programming error in the DES implementation used in crypt()
when handling input which contains characters that can not be represented
with 7-bit ASCII.

III. Impact

When the input contains characters with only the most significant bit set
(0x80), that character and all characters after it will be ignored.

IV. Workaround

No workaround is available, but systems not using crypt(), or which only
use it to handle 7-bit ASCII are not vulnerable. Note that, because
DES does not have the computational complexity to defeat brute force
search on modern computers, it is not recommended for new applications.

V. Solution

Perform one of the following:

1) Upgrade your vulnerable system to 7-STABLE, 8-STABLE, or 9-STABLE,
or to the RELENG_7_4, RELENG_8_3, RELENG_8_2, RELENG_8_1, or RELENG_9_0
security branch dated after the correction date.

2) To update your vulnerable system via a source code patch:

The following patches have been verified to apply to FreeBSD 7.4,
8.3, 8.2, 8.1 and 9.0 systems.

a) Download the relevant patch from the location below, and verify the
detached PGP signature using your PGP utility.

# fetch http://security.FreeBSD.org/patches/SA-12:02/crypt.patch
# fetch http://security.FreeBSD.org/patches/SA-12:02/crypt.patch.asc

# cd /usr/src
# patch < /path/to/patch
# cd /usr/src/lib/libcrypt
# make obj && make depend && make && make install

NOTE: On the amd64 platform, the above procedure will not update the
lib32 (i386 compatibility) libraries. On amd64 systems where the i386
compatibility libraries are used, the operating system should instead
be recompiled as described in
<URL:http://www.FreeBSD.org/handbook/makeworld.html>

3) To update your vulnerable system via a binary patch:

Systems running 7.4-RELEASE, 8.3-RELEASE, 8.2-RELEASE, 8.1-RELEASE,
or 9.0-RELEASE on the i386 or amd64 platforms can be updated via the
freebsd-update(8) utility:

# freebsd-update fetch
# freebsd-update install

VI. Correction details

The following list contains the revision numbers of each file that was
corrected in FreeBSD.

CVS:

Branch                                                           Revision
Path
– ————————————————————————-
RELENG_7
src/secure/lib/libcrypt/crypt-des.c                           1.16.24.1
RELENG_7_4
src/UPDATING                                            1.507.2.36.2.10
src/sys/conf/newvers.sh                                  1.72.2.18.2.13
src/secure/lib/libcrypt/crypt-des.c                           1.16.40.2
RELENG_8
src/secure/lib/libcrypt/crypt-des.c                           1.16.36.2
RELENG_8_3
src/UPDATING                                             1.632.2.26.2.4
src/sys/conf/newvers.sh                                   1.83.2.15.2.6
src/secure/lib/libcrypt/crypt-des.c                       1.16.36.1.8.2
RELENG_8_2
src/UPDATING                                            1.632.2.19.2.10
src/sys/conf/newvers.sh                                  1.83.2.12.2.13
src/secure/lib/libcrypt/crypt-des.c                       1.16.36.1.6.2
RELENG_8_1
src/UPDATING                                            1.632.2.14.2.13
src/sys/conf/newvers.sh                                  1.83.2.10.2.14
src/secure/lib/libcrypt/crypt-des.c                       1.16.36.1.4.2
RELENG_9
src/secure/lib/libcrypt/crypt-des.c                           1.16.42.2
RELENG_9_0
src/UPDATING                                              1.702.2.4.2.4
src/sys/conf/newvers.sh                                    1.95.2.4.2.6
src/secure/lib/libcrypt/crypt-des.c                       1.16.42.1.2.2
– ————————————————————————-

Subversion:

VII. References

http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2012-2143

The latest revision of this advisory is available at
http://security.FreeBSD.org/advisories/FreeBSD-SA-12:02.crypt.asc

Liberdade ou prisão?

Posted by gondim | Posted in FreeBSD, Software Livre, Tecnologia | Posted on 30-05-2012

Tags:clang, gcc, llvm

5

Hoje acordei e resolvi abordar algo que realmente sempre me irritou. Algumas pessoas que pregam a liberdade muitas das vezes distorcem o que é liberdade em prol do fanatismo que criaram em suas cabeças. Chega ao ponto de tentar obrigar algo à ser livre de determinada maneira. Porque se não for assim não será livre o suficiente.

Isso muito me lembra fatos religiosos, que não vou citar nomes mas, que vemos por aí o tempo todo onde a religião de fulano é a melhor porque é a certa e a do sicrano é a errada. Assim como na religião qualquer coisa que impomos estamos retirando a liberdade daquela pessoa de escolher. Mostrar e ajudar no caminho à seguir é uma forma de ajudar mas sem impor nada. No nosso mundo do software livre é a mesma coisa. Vejo muitas pessoas brigando entre si e afirmando que suas distribuições GNU/Linux são melhores, mais simples, mais tradicionais. Sempre as mesmas desculpas para as desavenças e para que tudo isso? Cada um gosta e usa o que quer. Qual o problema de uma pessoa gostar de usar um Microsoft Windows? Se ele tem dinheiro e quer pagar pela licença de uso então é a escolha dele, a liberdade que ele tem de decidir e nós como seres humanos deveríamos entender isso e respeitar.

O fato de ser pago e fechado não torna um programa ruim ou cheio de bugs. Todos os sistemas tem o seu valor e a sua aplicação. A Apple está aí para provar o quanto um sistema fechado e proprietário pode agradar à tanta gente no mundo. Ah! Mas o sistema da Apple é baseado em FreeBSD. Sim é sim mas muita coisa foram eles que desenvolveram e fecharam. Eu acho justo sim é existir opções livres para que as pessoas sem recursos possam usar e ter acesso à mesma tecnologia.

Liberdade na Informação deveria ser um direito de todos, da humanidade.

Eu citei distribuições GNU/Linux como exemplo mas são só um exemplo de muitos. Se formos mais à fundo e analisarmos o caso da licença GPL v3 na qual os novos compiladores GCC à partir da versão > 4.2, estão incorporando. Qualquer programa compilado com o GCC licenciado na GPL v3 está sujeito às regras impostas por esta licença e isso não está agradando muita gente, inclusive ao Linus Torvalds. Devido à isso, muitos projetos estão ajudando e migrando para o uso do Clang/LLVM (licença BSD) com o intuito de abandonar o GCC.

Imagine que se você compilar um programa usando um compilador GCC com licença GPL v3 seu programa automaticamente passa à adotar a GPL v3 como sua licença e fica obrigado à seguir suas regras. Bem, como muitos dizem isso foi um tiro no pé para o Richard Stallman. Agora o Clang/LLVM passa à ser o grande objetivo e todo esforço está sendo colocado para que no FreeBSD 10.0 tanto o sistema quanto os ports possam ser 100% compiláveis com o Clang. Atualmente, para a comunidade FreeBSD, qualquer programa que não possa ser compilado com o Clang possui um bug e precisa ser corrigido o quanto antes.

Na minha visão a GPL v3 vai de contra qualquer coisa que se diga livre e a jogada do Stallman era a de querer obrigar à todos que aceitassem a GPL v3 mudando a licença de um dos maiores compiladores livres que tínhamos.

Tudo isso é notícia velha e já acontece faz um bom tempo mas é sempre bom relembrar.

“O homem livre é um lutador e a liberdade é algo que se conquista”
Nietzche

Melhorando a segurança no FreeBSD – Parte 3

Posted by gondim | Posted in Dicas, FreeBSD, Segurança, Shell Script | Posted on 25-05-2012

Tags:crontab, periodic, ssmtp

2

Hoje venho falar de um complemento à segurança que é a visualização diária dos logs. Todo sysadmin deve olhar os logs diariamente para verificar possíveis problemas, tentativas de acessos não autorizados, ataques aos seus serviços, problemas com o hardware e por aí vai. Os logs estão aí para nos ajudar e embora seja um serviço trabalhoso, cansativo e chato, são os logs que nos salvam muitas das vezes.

O FreeBSD vem com uma ferramenta chamada Periodic que é um conjunto de shell scripts prontos e rodado pelo cron. Esses scripts são localizados em /etc/periodic, separados por:

daily
weekly
monthly
security

Os scripts nesses diretórios rodam diariamente, semanalmente e mensalmente. Os scripts em security também rodam diariamente mas são relacionados com segurança.

Se você gosta de aprender coisas novas e entende de shell script, dê uma olhada nesses scripts pois são muito interessantes e usam os comandos do sistema para isso. É uma forma de aprender mais sobre o sistema.

Nesse post, vamos instalar o portaudit, uma ferramenta que usamos para checar se temos alguma vulnerabilidade em pacotes que foram instalados do ports. Instalaremos o pacote ssmtp para envio dos logs por e-mail, para os servidores que vamos querer monitorar mas sem a necessidade de se ter um servidor de correio local. Por último faremos uma configuração no Periodic para que ele nos envie esses relatórios de segurança, diários, semanais e mensais.

Vamos começar com o portaudit que após instalado já adiciona um script dele para o periodic. O portaudit é usado para baixar uma listagem de vulnerabilidades do VuXML e checar se você tem alguma vulnerabilidade relacionada. Em caso positivo uma mensagem será mostrada apontando a vulnerabilidade ou vulnerabilidades que você tenha.

# cd /usr/ports/ports-mgmt/portaudit
# make install clean
# rehash <- se tiver usando csh

O portaudit, como eu disse anteriormente, já instala um script no periodic conforme abaixo:

# pkg_info -L portaudit-0.6.0
Information for portaudit-0.6.0:

Files:
/usr/local/man/man1/portaudit.1.gz
/usr/local/sbin/portaudit
/usr/local/etc/portaudit.pubkey
/usr/local/etc/portaudit.conf.sample
/usr/local/etc/periodic/security/410.portaudit

Quando quiser checar manualmente por vulnerabilidades basta executar: portaudit -Fda

Nesse momento vamos instalar o ssmtp. Esse programa é útil quando a máquina monitorada não é um servidor de e-mail e você não quer instalar um SMTP Server só para enviar os relatórios do periodic. Se a máquina estiver rodando um Servidor de Correio, não instale o ssmtp pois ele irá desconfigurar o seu servidor. Nesse caso pule a configuração abaixo e vá direto para a configuração do periodic.

# cd /usr/ports/mail/ssmtp
# make install clean
# make replace
# rehash <- se tiver usando csh

Continuando a configuração do ssmtp, vamos precisar alterar 2 arquivos apenas que ficam em /usr/local/etc/ssmtp. Vamos supor que eu queira usar uma conta de e-mail qualquer, em algum servidor, para enviar os relatórios. Vamos aos dados fictícios abaixo:

servidor de e-mail: smtp.teste.com.br – porta 587/tcp para envio de e-mail autenticado conforme recomendação do Comitê Gestor.
conta de e-mail: relatorio@teste.com.br
senha da conta de e-mail: zUngA2378

Iremos usar esses dados acima para o envio de qualquer e-mail desse servidor que estamos configurando. Agora faremos o seguinte:

# cd /usr/local/etc/ssmtp
# touch revaliases
# touch ssmtp.conf
# chmod 640 revaliases ssmtp.conf
# chown root:ssmtp revaliases ssmtp.conf

Dentro do arquivo ssmtp.conf colocaremos a seguinte configuração do nosso exemplo:

root=postmaster
mailhub=smtp.teste.com.br:587
rewriteDomain=teste.com.br
hostname=_HOSTNAME_
UseSTARTTLS
AuthUser=relatorio@teste.com.br
AuthPass=zUngA2378

Dentro do arquivo revaliases colocaremos a configuração abaixo:

root:relatorio@teste.com.br:smtp.teste.com.br:587

Lembrando que esses dados citados são fictícios e você deve substituí-los pelos seus dados reais.

Feito essas configurações você pode testar enviando um e-mail para você dessa forma:

# mailx -s teste joaobobo@gmail.com <<EOF
Teste de envio de e-mail.
EOF

Bem, se você fez o teste acima sem trocar o e-mail: joaobobo@gmail.com pelo seu e-mail, então pare por aqui e estude mais. 🙂

Se tudo der certo você receberá um e-mail vindo do e-mail configurado no ssmtp e provando que está tudo funcionando como deveria.

Vamos agora finalizar a nossa configuração do periodic. Criaremos o arquivo /etc/periodic.conf e dentro deste colocaremos essas 5 linhas abaixo:

#!/bin/sh
daily_output=”joaobobo@gmail.com”
weekly_output=”joaobobo@gmail.com”
monthly_output=”joaobobo@gmail.com”
daily_status_security_output=”joaobobo@gmail.com“

Nas linhas acima estaremos enviando os relatórios diários, semanais, mensais e de segurança para o e-mail: joaobobo@gmail.com.

Você pode consultar o arquivo /etc/defaults/periodic.conf para servir de referência e não deve alterar esse arquivo. Se quiser usar alguma variável de lá, copie ela e use no /etc/periodic.conf.

Bem, feito isso aguarde os relatórios que eles chegarão conforme configurado no /etc/crontab.

# Perform daily/weekly/monthly maintenance.
1       3       *       *       *       root    periodic daily
15      4       *       *       6       root    periodic weekly
30      5       1       *       *       root    periodic monthly

É isso e vejo vocês em breve.

PBI: Entendendo como funciona o formato de pacotes do PC-BSD.

Posted by lgvalentim | Posted in Dicas, FreeBSD | Posted on 24-05-2012

Tags:pbi, pc-bsd, pcbsd

1

O fato do PC-BSD ter uma instalacão fácil, intuitiva e agradável é sim um fato importante para sua popularizacão. Ser um sistema estável, de alta performance e seguro claramente não é suficiente para sua popularizacão em ambiente Desktop. Já, ser de fácil uso e ter um resultado rasoável por padrão após a instalacão, também é muito relevante para o perfil de usuários que o PC-BSD se destina: o usuário doméstico típico.

Porém, um dos principais fatores de destaque do PC-BSD no que tange a facilidade de uso é o seu sistema de instalacão de aplicacões de terceiros, o PBI: Push Button Installer, ou Instalador ao Apertar do Botão. O PBI é um formato especial e exclusivo do PC-BSD. Apesar de podermos usar pacotes pré-compilados (pkg_add) ou compilar a aplicacão localmente com a Colecão de Ports do FreeBSD, o formato padrão não é nenhum dos dois, e sim o PBI, que analisaremos agora em mais detalhes.

O Formato PBI – Visão Superficial

O formato de pacotes do instalador PBI é simples, parte do princípio que um PBI vai sempre instalar a aplicacão, todas as bibliotecas e dependências dessa aplicacão, em um compartimento único e isolado. Dessa forma não há conflitos de bibliotecas, não há também conflitos entre versões de dependências, nem há dependência da própria ABI nativa do sistema operacional.

A idéia por trás do conceito que o PBI trás é de um instalador que vai instalar aplicacões que vão rodar em qualquer versão do PC-BSD, e principalmente, que vai continuar plenamente funcional mesmo após atualizacões mesmo as mais radicais, com troca plena de ABI, com tanto que uma compatibilidade mínima seja mantida entre o sistema novo e suas versões anteriores – em kernel, os COMPAT_FREEBSD4, COMPAT_FREEBSD5, COMPAT_FREEBSD6, COMPAT_FREEBSDX;

Para isso, os arquivos com extensão .pbi são interpretados pelo PC-BSD como instalacão e são considerados executáveis. Esses executáveis são divididos essencialmente em quatro partes:

A primeira é a biblioteca de carregamento (o loader) que permite que o .pbi seja interpretado como um executável ELF. Ou seja são os Elf Loader Headers. A segunda parte contém embarcado o ícone da aplicacão que será instalada. A terceira camada tem as directivas e dados de configuracão do .pbi que identificam o que, onde e como será instalado. E finalmente a quarta etapa, são todos os dados da aplicacão, biblitecas e dependências, bem como os scripts que serão instalados.

O produto final de um arquivo .pbi é um executável auto-instalável:

eksffa@pcbsd% file JavaJRE1.6.0-PV0.pbi
JavaJRE1.6.0-PV0.pbi: ELF 32-bit LSB executable, Intel 80386, version 1 (FreeBSD), for FreeBSD 7.0 (700109), dynamically linked (uses shared libs), FreeBSD-style, not stripped

eksffa@pcbsd% brandelf ./JavaJRE1.6.0-PV0.pbi
File ‘./JavaJRE1.6.0-PV0.pbi’ is of brand ‘FreeBSD’ (9).

Que de fato, é linkado dinamicamente apenas a própria ABI nativa (libc):

eksffa@pcbsd% ldd ./JavaJRE1.6.0-PV0.pbi
./JavaJRE1.6.0-PV0.pbi:
libc.so.7 => /lib/libc.so.7 (0x2807e000)

E cujo prefix de instalacão é fora do padrão FreeBSD, quebra a hier(7) e também a especificacão POSIX, e fica isolado em /Programs, não tocando qualquer outro arquivo em infra-estrutura fora dessa hierarquia.

Entendendo o funcionamento de um Produto Instalado a partir de um PBI

Aqui chega a parte onde a abordagem por trás de um produto resultante de um PBI instalado deve ser avaliado e entendido. Os binários e bibliotecas criados de um PBI são exatamente iguais os criados da compilacão genérica de um Ports ou a instalacão de um package binários. O produto é o mesmo, mas sua estrutura instalada e a forma como são carregados, é a diferencão.

O coracão por trás do PBI é uma idéia simples, completamente funcional, mas com alguns efeitos colaterais. Todo binário já acompanha suas dependências e suas bibliotecas, e esses são isolados, e utilizados exclusivamente para aquela aplicacão.

A estrutura da instalacão de um PBI se baseia que tudo será instalado no /Programs (que por sua vez é um link simbólico para o /usr/Programs); e abaixo dele temos algumas estruturas, nem sempre todas utilizadas. A saber:

Programs/
Programs/bin/
Programs/lib/
Programs/etc/
Programs/rc.d/
Programs/rc.conf
Programs/<aplicacão>/

Todas aplicacões são instaladas em /Programs/<aplicacão>/, que é sempre constituído da seguinte organizacão hierárquica:

Programs/<aplicacão>/bin/
Programs/<aplicacão>/.sbin/
Programs/<aplicacão>/autolibs/
Programs/<aplicacão>/share/
Programs/<aplicacão>/libs (lincado para ./autolibs local)

Além disso temos sempre scripts executáveis:

Programs/<aplicacão>/PBI.FirstRun.sh
Programs/<aplicacão>/PBI.RemoveScript.sh
Programs/<aplicacão>/PBI.RemoveScript2.sh
Programs/<aplicacão>/PBI.SetupScript.sh
Programs/<aplicacão>/PBI.UpdateURL.sh

Os executáveis acima são rotinas executadas na primeira inicializacão da aplicacão depois de instalada, um script auxiliar que permite ao sistema de atualizacão de PBI avaliar se há atualizacões do PBI em questão, e por último os outros são rotinas de deinstalacão da aplicacão.

O mais importante é o:

Programs/<aplicacão>/autolibs/

Isso porque nessa estrutura estão todas, todas a bibliotecas de que o binário depende, bem como suas dependências, sejam essas bibliotecas ou aplicacões. Ou seja quando a aplicacão é executava, o contexto de bibliotecas dinâmicas do linker do loader (carregador) é isolado, e as bibliotecas disponíveis para aquele contexto de execussão é exclusivamente as que estivirem em Programs/<aplicacão>/autolibs/.

Inteligente não? Dessa forma não importa a ABI do sistema operacional, nem importa que bibliotecas existam ou não, que dependências existam ou não no restante do sistema, pois tudo que a aplicacão precisa, ela já “traz consigo”. Quase como se fosse um binário compilado estáticamente. Porém, não é estático, é dinâmico, e apesar de em disco haver redundância de bibliotecas, em memória os objetos iguais são sempre alocados em memória shadow, não havendo o mesmo consumo de memória que haveria se fossem todas aplicacões estáticamente compiladas.

O binário de inicializacão real (o verdadeiro produto da instalacão) fica disponível em:

Programs/<aplicacão>/bin/

Porém, o ambiente de execussão desse binário acontece através do que fica disponívem em:

Programs/bin/<aplicacão>

Que por sua vez é um link simbólico, que se referencia a um shell script disponível em:

Programs/<aplicacão>/.sbin/

E ai sim, esse shell script é onde fica a sacada, o pulo do gato do isolamento de contexto de bibliotecas. Vejamos um exemplo prático, o amsn instalado, instala um arquivo .desktop no Desktop, que é o link para a aplicacão, vejamos:

[Desktop Entry]
Name=aMSN
Exec=/Programs/aMSN0.97.2_1/.sbin/amsn
Type=Application
Path=/Programs/aMSN0.97.2_1/
Icon=/Programs/aMSN0.97.2_1/amsn.png

Ou seja ao clicar nesse ícone, é executado o /Programs/aMSN0.97.2_1/.sbin/amsn, que por sua vez é um link simbólico para um shell script:

% ls -l /Programs/bin/amsn
lrwxr-xr-x 1 root wheel 33 10 Dez 21:11 /Programs/bin/amsn -> /Programs/aMSN0.97.2_1/.sbin/amsn

O Executável de Inicializacão da Aplicacão

O shell script que faz o isolamento do contexto das bibliotecas dinâmicas e carrega a aplicacão pode ter algumas variacões, mas a essência geral é a seguinte:

A variável de ambiente LD_LIBRARY_PATH é populada, e seu único conteúdo é o Programs/<aplicacão>/autolibs/ ; com essa variável definida assim, o binário é executado em Programs/<aplicacão>/bin/<aplicacão>. Dessa forma qualquer biblioteca ou dependência que o binário precisa, só tem o Programs/<aplicacão>/autolibs/ onde carregar. Esse é o coracão por trás do ambiente instalado por um PBI.

Outros arquivos podem ser necessários, caso em que outras variáveis são populadas permitindo acesso as demais estruturas. Mas normalmente são apenas arquivos de referência de configuracão e comportamento, como share, ícones, configuracões padrão, diretivas de controle, etc.

Seguindo o estudo vamos analisar o que temos para iniciar o amsn:

#!/bin/sh
# Auto-Generated by PC-BSD
PATH=”/Programs/aMSN0.97.2_1/bin:$PATH”; export PATH
LANG=”`grep ^Language= ~/.kde/share/config/kdeglobals | cut -d “=” -f2`”; export LANG
LD_LIBRARY_PATH=”/Programs/aMSN0.97.2_1/autolibs/” ; export LD_LIBRARY_PATH
STDLOG=”${HOME}/.$$stdout”
STELOG=”${HOME}/.$$stderr”
(((( /Programs/aMSN0.97.2_1/bin/amsn “$@” || /PCBSD/bin/CrashHandler “bin/amsn” “${STDLOG}” “${STELOG}” ) | tee $STDLOG) 3>&1 1>&2 2>&3 | tee $STELOG) 3>&1 1>&2 2>&3)

rm $STDLOG >/dev/null 2>/dev/null
rm $STELOG >/dev/null 2>/dev/null

É esse o esqueleto padrão. Podem haver variacões, e de fato a infra-estrutura do PBI permite que hajam, para satisfazer os todos possíveis perfis de necessidade de aplicacões. Mas as variacões são apenas uma repeticão da idéia geral acima.

Avaliacão da Abordagem PBI

As impressões sobre a abordagem acima são as mais variadas. Sobre o PBI, já tivemos opinião de desenvolvedores Red Hat que mantém o padrão RPM, já tivemos opiniões de empacotadores Debian acostumados com os formatos de pacotes do Debian e toda a (bem criteriosa e inteligente, diga-se de passagem) estrutura de pacotes do Debian, e a opinião de Port Managers do Projeto FreeBSD, bem como mantenedores do PkgSrc.

De forma geral todos acham a idéia inteligente, porém, inadequada. O motivo é claro, ninguém gosta de ver tamanha redundância de bibliotecas e dependências como os PBI instalam. Porém, todos concordam, que poucas abordagens tem resultado tão prático e funcional. E acima de tudo, essa é a única abordagem livre de conflitos e problemas de dependências.

Efeitos Colaterais

Pro usuário final, porém, as consequências negativas da abordagem do PBI são duas: os PBI de forma geral são maiores do que poderiam ser, o download tem que trazer junto todas as dependências e bibliotecas que, de certa forma, podem já estar presentes no autolibs/ de alguma outra aplicacão ou na própria base do sistema operacional.

A segunda consequência é o espaco em disco. A abordagem dos PBI ocupa muito mais espaco em disco exatamente devido a essa redundância de bibliotecas e dependências. Em minhas análises, um conjunto simples de aplicacões, Firefox, aMSN, OpenOffice e Java, o consumo de espaco em disco é 34% superior com PBI do que instalado por pacote (package) pré-compilado. Se comparado com aplicacões compiladas localmente e com grande nível de customizacão de Build Time a diferenca pode ser ainda maior.

Resultados Obtidos pela Abordagem PBI

Os resultados conseguidos com essa abordagem porém, são os melhores possíveis: facilidade de uso, efetividade, e um resultado final sempre funcional com virtualmente nenhuma chance de problemas, conflitos ou falhas de dependência. No geral pesando as desvantagens do maior espaco em disco, as vantagens justificam a popularizacão do formato PBI por usuários típicos do PC-BSD.

fonte: fug-br – Por P. Tracanelli (FreeBSD Brasil)

Melhorando a segurança no FreeBSD – Parte 2

Posted by gondim | Posted in Dicas, FreeBSD, Segurança | Posted on 20-05-2012

Tags:blowfish, chflags, FreeBSD, log_in_vain, passwd, ttys

0

Dando continuidade nas melhorias de segurança no FreeBSD veremos mais algumas coisas que não foram abordadas aqui. O usuário root sempre foi um cara muito privilegiado e por isso devemos evitá-lo ao máximo e também não permitir que outras pessoas usem ele. Logicamente que segurança física sempre foi o Calcanhar de Aquiles da Segurança da Informação, mas podemos tomar alguns cuidados. Abaixo vamos seguir algumas dicas:

Remoção do usuário “toor”. Não tem utilidade para o sistema e possui “UID 0” que é um perigo para o sistema. Reparem que o perigo não está no nome do usuário e sim no UID (User ID) que sendo 0, é o grande perigo. Só o nome root não seria perigoso se o UID dele fosse diferente de 0.

Para remover o toor basta executar: vipw ir na linha abaixo e apagar teclando “dd”, depois “shift :” e “wq!” para sair gravando. Bem precisa conhecer um pouco de vi. 🙂

toor:*:0:0::0:0:Bourne-again Superuser:/root:

Outra coisa é retirar o shell de todos os usuários que não necessitarem de shell. Serviços não precisam que seus usuários tenham shell. Para isso verifique como está o seu /etc/master.password com o vipw. No FreeBSD 9.0 eles já são instalados com /usr/sbin/nologin como shell das contas. Mas quem ainda usa versões anteriores vão precisar alterar. Deve ficar parecido com o exemplo abaixo:

# $FreeBSD: release/9.0.0/etc/master.passwd 218047 2011-01-28 22:29:38Z pjd $
#
root:$1$ensO.a5U$02Vji3o598eieKtAf6Lpm.:0:0::0:0:Charlie &:/root:/usr/local/bin/bash
daemon:*:1:1::0:0:Owner of many system processes:/root:/usr/sbin/nologin
operator:*:2:5::0:0:System &:/:/usr/sbin/nologin
bin:*:3:7::0:0:Binaries Commands and Source:/:/usr/sbin/nologin
tty:*:4:65533::0:0:Tty Sandbox:/:/usr/sbin/nologin
kmem:*:5:65533::0:0:KMem Sandbox:/:/usr/sbin/nologin
games:*:7:13::0:0:Games pseudo-user:/usr/games:/usr/sbin/nologin
news:*:8:8::0:0:News Subsystem:/:/usr/sbin/nologin
man:*:9:9::0:0:Mister Man Pages:/usr/share/man:/usr/sbin/nologin
sshd:*:22:22::0:0:Secure Shell Daemon:/var/empty:/usr/sbin/nologin
smmsp:*:25:25::0:0:Sendmail Submission User:/var/spool/clientmqueue:/usr/sbin/nologin
mailnull:*:26:26::0:0:Sendmail Default User:/var/spool/mqueue:/usr/sbin/nologin
bind:*:53:53::0:0:Bind Sandbox:/:/usr/sbin/nologin
proxy:*:62:62::0:0:Packet Filter pseudo-user:/nonexistent:/usr/sbin/nologin
_pflogd:*:64:64::0:0:pflogd privsep user:/var/empty:/usr/sbin/nologin
_dhcp:*:65:65::0:0:dhcp programs:/var/empty:/usr/sbin/nologin
uucp:*:66:66::0:0:UUCP pseudo-user:/var/spool/uucppublic:/usr/local/libexec/uucp/uucico
pop:*:68:6::0:0:Post Office Owner:/nonexistent:/usr/sbin/nologin
www:*:80:80::0:0:World Wide Web Owner:/nonexistent:/usr/sbin/nologin
hast:*:845:845::0:0:HAST unprivileged user:/var/empty:/usr/sbin/nologin
nobody:*:65534:65534::0:0:Unprivileged user:/nonexistent:/usr/sbin/nologin

Reparem que só o root tem shell que no meu caso é o bash.

Próxima melhoria seria aumentar a segurança da senha do root trocando md5 para blowfish. Para essa tarefa precisamos editar o arquivo /etc/login.conf:

default:\
:passwd_format=md5:\

Para:

default:\
:passwd_format=blf:\

Após alterar o arquivo login.conf precisamos rodar o seguinte comando para que seja gerado o /etc/login.conf.db, cujo arquivo é o que o sistema realmente usa.

# cap_mkdb /etc/login.conf

Mas não acabamos com a senha ainda. Após feito isso precisamos alterar novamente as senhas que desejamos para que essas agora estejam em blowfish e isso pode ser feito com o comando passwd. Reparem na diferença dos tipos:

MD5:

root:$1$9kaWUo5i$fIoOwZFsBsZG9WR/.nqhh1:0:0::0:0:Charlie &:/root:/usr/local/bin/bash

Blowfish:

root:$2a$04$qXWwmvWbpMrp7qpwDbxX/uVccYR3jfhET/hD1U2h9ZN7QyP13yW26:0:0::0:0:Charlie &:/root:/usr/local/bin/bash

Blowfish é bem mais forte (seguro) que md5. Obs: antigamente se usava o /etc/auth.conf para essa configuração.

Outra coisa boa é definir um idle timeout para o root, no caso de você acidentalmente esquecer o usuário root logado no servidor. Se você estiver usando bash como shell, basta adicionar essa variável em /etc/profile:

TMOUT=300

A variável acima trabalha em segundos, ou seja, se o root ficar sem fazer nada por 5 minutos, automaticamente este é deslogado.

Se estiver usando csh como shell, adicione a seguinte linha em /etc/csh.login:

set autologout=5

O autologout trabalha em minutos e vai fazer a mesma função do TMOUT no csh.

Se usa outro shell você precisará pesquisar se este possui uma variável de controle para essa finalidade.

Infelizmente no sh não existe um equivalente para essa finalidade.

Continuando com a nossa melhoria de segurança se você não quiser que alguém logue como root na console do seu servidor podemos editar o arquivo /etc/ttys cujo exemplo está abaixo:

# If console is marked “insecure”, then init will ask for the root password
# when going to single-user mode.
console none                            unknown off secure
#
ttyv0   “/usr/libexec/getty Pc”         xterm   on secure
# Virtual terminals
ttyv1   “/usr/libexec/getty Pc”         xterm   on secure
ttyv2   “/usr/libexec/getty Pc”         xterm   on secure
ttyv3   “/usr/libexec/getty Pc”         xterm   on secure
ttyv4   “/usr/libexec/getty Pc”         xterm   on secure
ttyv5   “/usr/libexec/getty Pc”         xterm   on secure
ttyv6   “/usr/libexec/getty Pc”         xterm   on secure
ttyv7   “/usr/libexec/getty Pc”         xterm   on secure
ttyv8   “/usr/local/bin/xdm -nodaemon” xterm   off secure
# Serial terminals
# The ‘dialup’ keyword identifies dialin lines to login, fingerd etc.
ttyu0   “/usr/libexec/getty std.9600”   dialup off secure
ttyu1   “/usr/libexec/getty std.9600”   dialup off secure
ttyu2   “/usr/libexec/getty std.9600”   dialup off secure
ttyu3   “/usr/libexec/getty std.9600”   dialup off secure
# Dumb console
dcons   “/usr/libexec/getty std.9600”   vt100   off secure

Basta mudar a coluna secure para insecure conforme abaixo:

# If console is marked “insecure”, then init will ask for the root password
# when going to single-user mode.
console none                            unknown off insecure
#
ttyv0   “/usr/libexec/getty Pc”         xterm   on insecure
# Virtual terminals
ttyv1   “/usr/libexec/getty Pc”         xterm   on insecure
ttyv2   “/usr/libexec/getty Pc”         xterm   on insecure
ttyv3   “/usr/libexec/getty Pc”         xterm   on insecure
ttyv4   “/usr/libexec/getty Pc”         xterm   on insecure
ttyv5   “/usr/libexec/getty Pc”         xterm   on insecure
ttyv6   “/usr/libexec/getty Pc”         xterm   on insecure
ttyv7   “/usr/libexec/getty Pc”         xterm   on insecure
ttyv8   “/usr/local/bin/xdm -nodaemon” xterm   off insecure
# Serial terminals
# The ‘dialup’ keyword identifies dialin lines to login, fingerd etc.
ttyu0   “/usr/libexec/getty std.9600”   dialup off insecure
ttyu1   “/usr/libexec/getty std.9600”   dialup off insecure
ttyu2   “/usr/libexec/getty std.9600”   dialup off insecure
ttyu3   “/usr/libexec/getty std.9600”   dialup off insecure
# Dumb console
dcons   “/usr/libexec/getty std.9600”   vt100   off insecure

Cuidado com a linha “console none unknown off insecure” porque se você colocar ela como insecure quando precisar entrar em sigle mode para recuperar algo no sistema, será pedido a senha de root. Isso pode ser ruim se caso estiver tentando recuperar senhas. Logo ficará ao seu critério colocar a console como insecure. Qualquer tty definida como insecure não será possível acessar como root.

Agora vamos restringir certos acessos, mas chequem se alguma aplicação de vocês precisará de acesso à um desses arquivos em específico:

# chflags noschg /usr/bin/crontab

# echo “root” > /var/cron/allow
# echo “root” > /var/at/at.allow
# chmod o= /etc/crontab
# chmod o= /usr/bin/crontab
# chmod o= /usr/bin/at
# chmod o= /usr/bin/atq
# chmod o= /usr/bin/atrm
# chmod o= /usr/bin/batch

# chflags schg /usr/bin/crontab

Alguns arquivos já tem vindo com proteções usando chflags e por isso precisamos removê-las para alterar as permissões e depois adiciona-las novamente. Para ver se algum arquivo está com chflags setado use o ls com o parâmetro “o”. Abaixo um exemplo:

# ls -laAGo/usr/bin/crontab
-r-sr-xr-x 1 root wheel schg 27404 Feb 9 15:17 /usr/bin/crontab

Repare na quinta coluna a flag schg que diz que esse arquivo é imutável.

Continuando… acima estamos restringindo o uso do cron e at somente para o root. Nenhum outro usuário do sistema poderá usá-los. Também estamos removendo as permissões de usuários regulares dos arquivos pertinentes ao cron e at.

Abaixo mais restrições aos usuários regulares para que não acessem alguns conteúdos pois não deveriam ser de interesse deles:

# chmod o= /etc/fstab
# chmod o= /etc/ftpusers
# chmod o= /etc/group
# chmod o= /etc/hosts
# chmod o= /etc/hosts.allow
# chmod o= /etc/hosts.equiv
# chmod o= /etc/hosts.lpd
# chmod o= /etc/inetd.conf
# chmod o= /etc/login.access
# chmod o= /etc/login.conf
# chmod o= /etc/newsyslog.conf
# chmod o= /etc/rc.conf
# chmod o= /etc/ssh/sshd_config
# chmod o= /etc/sysctl.conf
# chmod o= /etc/syslog.conf
# chmod o= /etc/ttys

Quanto aos logs também pode ser feito uma coisa interessante com chflags mas tenham em mente que fazendo isso o rotacionamento de logs não funcionará mais. Minha sugestão, se você quiser uma boa segurança nesse aspecto, é você montar um servidor de logs e configurar os demais servidores para enviarem os logs para esse servidor. Aí sim nesse servidor específico você poderia até fazer o que está abaixo:

# chmod o= /var/log
# chflags sappnd /var/log
# chflags sappnd /var/log/*

Com essa conf acima, os arquivos de log estarão em append only e não poderá ser removida qualquer linha deles, somente adicionada.

Mais restrições à usuários regulares para que não tenham informações importantes do sistema como quem está logado, listar jails, quem logou e por aí vai:

# chmod o= /usr/bin/users
# chmod o= /usr/bin/w
# chmod o= /usr/bin/who
# chmod o= /usr/bin/lastcomm
# chmod o= /usr/sbin/jls
# chmod o= /usr/bin/last
# chmod o= /usr/sbin/lastlogin

Desabilitar o uso do rlogin e do rsh:

# chflags noschg /usr/bin/rlogin /usr/bin/rsh

# chmod ugo= /usr/bin/rlogin
# chmod ugo= /usr/bin/rsh

# chflags schg /usr/bin/rlogin /usr/bin/rsh

O syslogd vem por default habilitado para receber logs e por isso abre uma porta de acesso ao mesmo. Como falei anteriormente acho mais seguro fazer isso em um servidor separado e por isso vamos desabilitar essa função no syslogd local e deixá-la habilitada no servidor de logs. O syslogd continuará funcionando do mesmo jeito só não haverá nenhuma porta escutando uma conexão.

# echo ‘syslogd_flags=”-ss”‘ >> /etc/rc.conf

Vamos partir agora para variáveis da systcl. Existem 2 variáveis que habilitam o recurso log_in_vain que é muito útil quando queremos saber se alguém está tentando acessar alguma porta de serviço que não esteja habilitada no nosso servidor. Para habilitar é muito simples adicione as linhas abaixo no seu /etc/sysctl.conf. Isso também pode ser habilitado pelo /etc/rc.conf, para isso consulte o /etc/defaults/rc.conf.

sysctl net.inet.tcp.log_in_vain=1
sysctl net.inet.udp.log_in_vain=1

Fazendo um teste de uma outra máquina, tentei fazer um telnet na máquina protegida (10.255.0.12) na porta 9998/tcp o que resultou no log abaixo:

/var/log/messages:May 20 11:52:11 protheus kernel: TCP: [192.168.255.1]:59486 to [10.255.0.12]:9998 tcpflags 0x2<SYN>; tcp_input: Connection attempt to closed port

Agora vamos bloquear que outros usuários possam ver processos de outros usuários, colocando a linha abaixo também no /etc/sysctl.conf:

security.bsd.see_other_uids=0

Muitas das coisas do post acima, retirei dessa documentação do Jon LaBass. Pelo menos as que achei mais interessantes e adicionei algumas mudanças pois uma coisa que foi citada em seu texto, ainda não existe implementação no FreeBSD que foi o caso do idletime no /etc/login.conf. Ela existe para uso de aplicações de terceiros mas não na base do FreeBSD, ou seja, o fato de setar ela não irá funcionar e por isso usei outros recursos como o TMOUT e o autologout. Existem outras alterações citadas por ele mas preferi expor apenas as que me interessei.

É isso aí pessoal e até a próxima.

Não deixem de ler o meu primeiro post sobre Melhorando a Segurança no FreeBSD com securelevel + chflags aqui.

Aviso importante! Mudanças na versão do PHP 5 em /usr/ports/lang/php5

Posted by gondim | Posted in Dicas, FreeBSD | Posted on 18-05-2012

Tags:PHP, php 5.4, php54

0

Para aqueles que estão usando o PHP 5.3 instalado à partir do /usr/ports/lang/php5 perceberão que após um “portsnap fetch update” a versão mudará para o PHP 5.4.3. Cuidado na hora de atualizar o PHP para não trocar de versão acidentalmente. O PHP 5.3 agora encontra-se em:

/usr/ports/lang/php53

Os desenvolvedores afirmam que são poucas as incompatibilidades entre versão 5.3 e a 5.4. Mas todo cuidado é bom e por isso aqui está a página informando as incompatibilidades.

As novidades dessa nova versão podem ser vistas aqui.

É isso aí pessoal. Aqui no meu sistema eu mudei os pacotes php5-… para php53-… usando o portmaster citado nesse post.

Grande abraço aos leitores daqui do blog.

Post em Destaque

Depurando programas no FreeBSD

Posted by gondim | Posted in FreeBSD, Segurança, Software Livre | Posted on 11-06-2012

Tags:openvpn, vpn

0

Posted by gondim | Posted in FreeBSD, Software Livre, Tecnologia | Posted on 07-06-2012

Tags:compatibilidade binária, emulação

2

Posted by gondim | Posted in FreeBSD, Tecnologia | Posted on 01-06-2012

Tags:conference, conferência, meetbsd

0

Posted by gondim | Posted in Dicas, FreeBSD | Posted on 31-05-2012

7

Posted by gondim | Posted in FreeBSD, Segurança | Posted on 30-05-2012

Tags:crypt, openssl

1

Posted by gondim | Posted in FreeBSD, Software Livre, Tecnologia | Posted on 30-05-2012

Tags:clang, gcc, llvm

5

Posted by gondim | Posted in Dicas, FreeBSD, Segurança, Shell Script | Posted on 25-05-2012

Tags:crontab, periodic, ssmtp

2

Posted by lgvalentim | Posted in Dicas, FreeBSD | Posted on 24-05-2012

Tags:pbi, pc-bsd, pcbsd

1

Posted by gondim | Posted in Dicas, FreeBSD, Segurança | Posted on 20-05-2012

Tags:blowfish, chflags, FreeBSD, log_in_vain, passwd, ttys

0

Posted by gondim | Posted in Dicas, FreeBSD | Posted on 18-05-2012

Tags:PHP, php 5.4, php54

0

Posts recentes

Categorias

Links

Administração