Cluster de Firewall com carp + pfsync

maio 21, 2007

Introdução
Para quem não conhece o assunto, com carp + pfsync é possível criar um cluster de firewalls de uma forma que elimine um único ponto de falha, e ainda por cima é totalmente transparente, uma máquina pode explodir que a outra irá assumir instantaneamente e você não vai perder se quer um misero pacote de seu download. CARP = Common Address Resolution Protocol, o carp é o principal responsável pelo compartilhamento de IP entre o cluster. É com ele que faremos a redundância das máquinas, se uma cair a outra irá assumir o ip setado no carp. Além do carp iremos utilizar o PFSYNC para fazer a sincronia de estados das conexões entre as máquinas, é por causa dele que se uma máquina cair e o tráfego for redirecionado para a outra a conexão não será cortada.

Requerimentos
Neste exemplo vou criar um cluster apenas entre duas máquinas, então vamos precisar de duas máquinas duh :P, cada uma delas com 3 placas de rede. Porque 3 placas? Simples, uma para a rede válida, outra para a rede privada, e a última como meio de sincronia dos estados das conexões entre as duas máquinas. Além disso iremos precisar de 8 IPs diferentes, 4 para cada máquina, 1 ip válido para cada máquina, 1 ip privado para cada máquina, mais 1 ip privado para cada máquina para sincronia (pfsync) e mais 2 ips virtuais que serão setados em cada carp, um público e outro privado. Não se assustem com a quantidade de ips utilizados, logo tudo isso irá ficar mais claro.

Configurações

CARP
Primeiro vamos criar as interfaces do carp, sim, elas funcionam como uma interface virtual :).
Um pequeno resumo dos ips:
fw01:
xl0 – 200.x.x.2
xl1 – 192.168.0.2
rl0 – 10.10.10.1
carp0 – 200.x.x.1
carp1 – 192.168.0.1
fw02:
xl0 – 200.x.x.3
xl1 – 192.168.0.3
rl0 – 10.10.10.2
carp0 – 200.x.x.1
carp1 – 192.168.0.1
Execute isso nas duas máquinas, não se preocupe com os parâmetros, irei explica-los:
# ifconfig carp0 create
# ifconfig carp1 create
Máquina 1:
# ifconfig carp0 vhid 1 pass senha carpdev xl0 advskew 0 200.x.x.1 netmask 255.255.255.0
# ifconfig carp0 vhid 2 pass senha carpdev xl1 advskew 0 192.168.0.1
netmask 255.255.255.0
Máquina 2:
# ifconfig carp0 vhid 1 pass senha carpdev xl0 advskew 128 200.x.x.1 netmask 255.255.255.0
# ifconfig carp0 vhid 2 pass senha carpdev xl1 advskew 128
192.168.0.1 netmask 255.255.255.0

Parâmetros
vhid: O Virtual Host ID. Este é um número único que é usado para identificar o grupo de redundância de outros nós na rede. Valores aceitos são 1 à 255.
pass:É a senha de comunicação entre os nós, evitando que algum engraçadinho entre na rede afim de snifar o tráfego.
carpdev: Aqui é especificado a qual interface o carp está conectado.
advskew: Ele define a prioridade da máquina, quanto menor o valor maior a prioridade, em nosso caso, se as duas máquinas estiverem no ar, a primerira irá funcionar como master.

PFSYNC
Agora vamos configurar o meio de sincronia entre os nós:
Máquina 1:
# ifconfig rl0 10.10.10.1 netmask 255.255.255.252
Máquina 2:
# ifconfig rl0 10.10.10.2 netmask 255.255.255.252
Nas duas máquinas:
# ifconfig pfsync0 syncdev rl0
Como estou utilizando apenas 2 máquinas eu interliguei as 2 através de um cabo cross, com isso eu evito que alguém tente conectar um cabo na rede (caso houvesse).

SYSCTL
Outra coisa importante é ativar o carp com o sysctl, estas são as possíveis entradas:
net.inet.carp.allow: Aceita entrada de pacotes CARP ou não. Padrão é 1 (sim).
net.inet.carp.preempt: Permite hosts dentro de um grupo de redundância ter um melhor advbase e advskew para tomar o lugar (preempt) do master. Adicionalmente, esta opção habilita failing over em todas as interfaces caso uma interface caia (down). Se uma interface física CARP cair, o CARP trocará o advskew para 240 em todas as outras interfaces CARP, em essência o failing termina por si mesmo. Esta opção é 0 (desabilitada) por padrão.
net.inet.carp.log: Loga pacotes CARP. O padrão é 0 (desabilitado).
net.inet.carp.arpbalance: Carrega balanceamento de tráfego entre múltiplos hosts no grupo de redundância. O padrão é 0 (desabilitado). Veja carp(4) para mais informações.
Precisamos ativar o preempt, para isso execute nas duas máquinas:
# sysctl -w net.inet.carp.preempt=1

Salvando as Configurações
Como o carp e o pfsync são tratados como interfaces, o arquivo de configuração a ser criado para eles é quase igual ao de uma placa de rede.
Crie os respectivos arquivos em cada uma das máquinas com os respectivos IPs:
/etc/hostname.carp0:
# inet 200.x.x.2 255.255.255.0 200.x.x.255 vhid 1 advskew 0 carpdev xl0 pass senha
/etc/hostname.carp1:
# inet 192.168.0.2 255.255.255.0 192.168.0.255 vhid 2 advskew 0 carpdev xl0 pass senha
/etc/hostname.rl0:
# inet 10.10.10.1 255.255.255.252 NONE
/etc/hostname.pfsync0:
# up syncdev rl0
E para finalizar habilite o preempt do carp no /etc/sysctl.conf

Testando
Depois de tudo configurado você verá algo do tipo em sua máquina:
[root@firewall01 admin]$ ifconfig
lo0: flags=8049 mtu 33224
groups: lo
inet 127.0.0.1 netmask 0xff000000
xl0: flags=8943 mtu 1500
lladdr 00:50:04:42:f1:c1
groups: egress
media: Ethernet 100baseTX full-duplex
status: active
inet 200.x.x.2 netmask 0xfffffff0 broadcast 200.x.x.255
xl1: flags=8943 mtu 1500
lladdr 00:50:04:42:aa:bb
media: Ethernet 100baseTX full-duplex
status: active
inet 192.168.0.2 netmask 0xffffff80 broadcast 192.168.0.255
rl0: flags=8843 mtu 1500
lladdr 00:15:f2:b0:80:3d
media: Ethernet 100baseTX full-duplex
status: active
inet 10.10.10.1 netmask 0xfffffffc broadcast 10.10.10.3
pflog0: flags=141 mtu 33224
pfsync0: flags=41 mtu 1460
pfsync: syncdev: rl0 syncpeer: 224.0.0.240 maxupd: 128
enc0: flags=0 mtu 1536
carp0: flags=8843 mtu 1500
carp: MASTER carpdev xl0 vhid 1 advbase 1 advskew 0
groups: carp
inet 200.x.x.1 netmask 0xfffffff0 broadcast 200.x.x.255
carp1: flags=8843 mtu 1500
carp: MASTER carpdev xl1 vhid 2 advbase 1 advskew 0
groups: carp
inet 192.168.0.1 netmask 0xffffff80 broadcast 192.168.0.255

Caso você execute ifconfig carp0 down, ou tirar um cabo de rede o carp0 da segunda máquina irá mudar de BACKUP para MASTER.
Existem três estados para uma interface do carp:
MASTER: Acho que dispensa comentários 🙂
BACKUP: Esse também 😀
INIT: INIT é quando a interface ainda não está no ar, é o que irá acontecer se você executar o ifconfig carpX down.

Firewall
Outra coisa importante a se fazer é liberar o tráfego do carp e pfsync no firewall 😀 Sem isso tudo o que foi feito anteriormente é inútil.
Não irei entrar em detalhes sobre o firewall agora, apenas insira isto no inicio de suas regras para garantir que tudo vai funcionar como esperado:
#libera carp entre as maquinas fw
pass quick on { $pfsync_if } proto pfsync
pass quick on { $ext_if $int_if } proto carp keep state
Não se esqueça de criar as variáveis definindo as interfaces para pfsync_if,etc.

Anúncios

OpenBSD – Apache – pf –

maio 21, 2007

Apache
O Apache já vem pré-instalado no OpenBSD, bastando apenas algumas modificações para o seu funcionamento desejado. No nosso exemplo, queremos rodar ele com suporte a PHP, então devemos instalar o PHP:
cd /usr/ports/www/php4
make
make install
/usr/local/sbin/php4-enable
E depois adicionar as seguintes linhas no /var/www/conf/httpd.conf, para ele aceitar seus scripts PHP:
LoadModule php4_module /usr/lib/apache/modules/libphp4.so
DirectoryIndex index.php index.html index.wml index.php3
AddType application/x-httpd-php .php .php3 .phtml
AddType application/x-httpd-php-source .phps

E então reiniciar o apache:
apachectl restart

pf
O OpenBSD ( a partir do 3.0) vem com o packetfilter (pf), que é um excelente filtro de pacotes, mas com uma configuração bem simples, toda dentro do arquivo “/etc/pf.conf” (nat.conf para nat). No nosso exemplo, usaremos a política de bloquear todo o acesso a nossa máquina, liberando apenas as portas usadas por nós (22,25,53,80 e 110). O acesso de saída será totalmente liberado. Nosso arquivo de configuração ficaria então desse modo:
#echo >> /etc/pf.conf


Firewall Transparente ou Uma Bridge Filtrada

maio 21, 2007

Introdução

Nos *BSD’s a maioria dos quesitos de segurança e serviços auxiliares são NATIVOS, o que torna muito fácil sua utilização. Em nosso caso, estamos usando o FreeBSD 4.7, em máquina Pentium 166 com 48 mB de RAM (Itautec Infoway), e o IPFW 🙂

Em primeiro lugar: pra que haveríamos de querer um treco dêsses aí? Será que um firewall convencional não atende nossas necessidades?

Bem, de fato a Bridge filtrada é medida adicional de segurança, algo que não vai pesar no orçamento (excessivamente, pelo menos) 🙂 e oferece um grau adicional de dificuldades ao eventual script-kid ou hacker, êsses monstros sempre dispostos a tirar nosso sono e (se acessarem nossos servidores), colocar em risco nosso caviar, festas anuais em Paris e viagens mensais ao Epicot Center, coisinhas que todos nós, Administradores de Rede, esforçamo-nos por oferecer às nossas familias. Lógico, não estou nêsse nível, mas vocês aí fora, seguramente, estão :-). Não se preocupem, não contarei ao Imposto de Renda, êsse esganado.

Embora a maioria dos colegas já saibam, de cor e salteado o que é uma bridge filtrada, permito-me repetir os conceitos:

Suponha que temos de um lado, um link que nos liga (via roteador/modem adsl/ cable modem) à internet, e de outro lado temos OU nossa máquina (o mais simples) OU um firewall fazendo NAT para um número qualquer de máquinas de nossa rede interna. Para efeitos de exposição, vou me limitar ao caso mais simples (minha casa), que dispunha de uma conexão ADSL (Speedy) de um lado e minha própria máquina de outro, ficando a bridge entre elas :-). Arte em ASCII:

|——> rl2 (192.168.10.10) /internet/——[bridge]—-/cliente/ ^ ^ |–rl0 | –rl1 rl2

É usada para contrôle, a partir de um notebook (por exemplo) ou outra máquina; O enderêço dessa placa deve ser DIFERENTE de qualquer outro eventualmente existente em nossa rede, ou seja, se estamos com uma rede em 192.168.1.0, podemos estabelecer essa placa como estando em rede 192.168.10.0 (ou 172.30.0.0, ou 10.0.0.0). Importa é que não seja acessível normalmente a partir de nossa própria rede, mesmo que no mesmo switch.

Não representado na ASCII-art, há um modem ADSL entre a internet e a bridge. Aqui é que vão começar as diferenças entre um firewall convencional e a bridge filtrada:

roteador: 200.204.151.65/26 –> é o modem ADSL cliente: 200.204.151.121/26 –> máquina interna

Tivéssemos um firewall convencional no lugar da bridge, e rl0 deveria ter um ip fixo, válido, enquanto em rl1 teríamos outro ip fixo, possívelmente um dos relacionados na RFC-1918, não roteável. A máquina cliente teria um ip dessa mesma classe/rede, ou seja (mais ASCII-art):

/internet/— oteador—–[firewall]—-/cliente/ ^ ^ ^ ^ 200.204.151.65——-| | | |—192.168.1.2..n 200.204.151.121–| |-192.168.1.1

Fazendo-se abstração completa do funcionamento disso, vamos ao que interessa: A bridge não tem enderêço em qualquer das placas. O conceito é de que tudo o que aparecer em uma delas é copiado para a outra. Contudo, antes de chegar à outra placa, vindo da Internet, o pacote de dados é analisado para saber se pode ou não atingir a máquina cliente. O pacote da máquina cliente poderá (ou não) sair para a Internet, sendo que, se houver expectativa de respostas, isso será inserido em uma tabela. Lógico, o processo é bem mais complexo, mas todos conhecem isso bem, não é mesmo? 😉

Isso nos permite montar um sistema de defesa mais sofisticado, por exemplo: (e tome ASCII-art):

/internet/— oteador–{bridge}—[firewall]—-/cliente(ou LAN)/ ^ ^ ^ ^ 200.204.151.65——-| | | |—192.168.1.2..n 200.204.151.121–| |-192.168.1.1

Nesse caso, o firewall está fazendo também NAT para a(s) máquina(s) cliente(s).

Resumo: alguém (na internet) já disse que a bridge filtrada é um fio inteligente. E é isso mesmo. Um fio, sem enderêços IP, que analisa os pacotes que por ela passam, bloqueando-os ou deixando-os passar, conforme as regras vigentes.

Optamos por um firewall do modêlo FECHADO, ou seja, tudo é bloqueado, salvo aquilo que é expressamente autorizado a trafegar. Pode ser que existam defensores do outro método (‘tudo aberto, fecho o que não quero’), mas prefiro o conceito de ‘tudo fechado, autorizo o que quero’. :-). Assim, com certeza, não deixo aberto algum furo que eu não queria, mas não lembrei de fechar 🙂

Configurando o kernel

Será necessária a reconfiguração do kernel, habilitando a bridge, e os itens relativos ao firewall:

options IPFIREWALL #firewall
options IPFIREWALL_VERBOSE #print information about
#options IPFIREWALL_FORWARD #enable transparent proxy support
options IPFIREWALL_VERBOSE_LIMIT=250 #limit verbosity
options RANDOM_IP_ID #−−−> vide LINT ;−)

# TCP_DROP_SYNFIN adds support for ignoring TCP packets with SYN+FIN. This
# prevents nmap et al. from identifying the TCP/IP stack, but breaks support
# for RFC1644 extensions and is not recommended for web servers.

#
options TCP_DROP_SYNFIN #drop TCP packets with SYN+FIN
# ICMP_BANDLIM enables icmp error response bandwidth limiting. You
# typically want this option as it will help protect the machine from
# D.O.S. packet attacks.

#
options ICMP_BANDLIM
# BRIDGE enables bridging between ethernet cards −− see bridge(4).
# You can use IPFIREWALL and DUMMYNET together with bridging.
#
options BRIDGE

Configuração

O arquivo rc.conf também deve ter algumas opções acrescidas ou modificadas:

### Basic network and firewall/security options: ###
firewall_enable="yes" # Set to YES to enable firewall functionality
firewall_flags="" # Flags passed to ipfw when type is a file
firewall_logging="yes" # Set to YES to enable events logging

firewall_quiet="NO" # Set to YES to suppress rule display
firewall_script="/etc/rc.firewall.bridge" # Which script to run to set up the firewall
ifconfig_rl0="up"
ifconfig_rl1="up"

ifconfig_rl2="inet 192.168.10.10 netmask 255.255.255.0"
sshd_enable="YES"

O script de firewall (/etc/rc.firewall.bridge), que não é o padrão da instalação mas sim um script nosso (seguindo muitas sugestões de outros colegas); Note-se o fato de que as placas de rede rl0 e rl1 são ativadas, mas não recebem qualquer número ip, ao contrário de rl2, que recebe um ip-addr convencional, dos relationados na RFC-1918.

Ufa, estamos quase lá :-)) Crie um arquivo chamado “sysctl.conf” em “/etc”. Ou, caso o mesmo já exista, acrescente o seguinte conteúdo:

#enablesbridge
net.link.ether.bridge=1
#tells bridge togo through the firewall
net.link.ether.bridge_ipfw=1
#tells bridge what interfaces are bridged
net.link.ether.bridge_cfg=rl0:1,rl1:1
#−−−−−−finetunning −−−> recolhido da internet :)

net.inet.tcp.sendspace=32768
net.inet.tcp.recvspace=32768
kern.ipc.somaxconn=1024
net.inet.icmp.drop_redirect=1
net.inet.icmp.log_redirect=1
net.inet.ip.redirect=0
net.inet6.ip6.redirect=0
net.inet.ip.sourceroute=0

net.inet.ip.accept_sourceroute=0
net.link.ether.inet.max_age=1200
net.inet.icmp.bmcastecho=0

Agora, vamos às nossas regras para o IPFW :−)

#
# Setup system for firewall service.
#
# Suck in the configuration variables.
if [ −r /etc/defaults/rc.conf ]; then
. /etc/defaults/rc.conf
source_rc_confs
elif [ −r /etc/rc.conf ]; then
. /etc/rc.conf

fi
############
# Set quiet mode if requested
#
case ${firewall_quiet} in
[Yy][Ee][Ss])
fwcmd="/sbin/ipfw −q"
;;
*)
fwcmd="/sbin/ipfw"
;;
esac
############
# Flush out the list before we begin.

#
${fwcmd} −f flush
############
# Only in rare cases do you want to change these rules
#
${fwcmd} add 100 pass all from any to any via lo0
${fwcmd} add 200 deny all from any to 
127.0.0.0/8
${fwcmd} add 300 deny ip from 127.0.0.0/8 to any
# If you're using 'options BRIDGE', uncomment the following line to pass ARP
${fwcmd} add 400 pass udp from 
0.0.0.0 2054 to 0.0.0.0
#−−−−−−−−−−>
oif=rl0
iif=rl1
iic=rl2
${fwcmd} add check−state
${fwcmd} add deny log ip from 10.0.0.0/8 to any via ${oif}

${fwcmd} add deny log ip from 172.16.0.0/12 to any via ${oif}
${fwcmd} add deny log ip from 192.168.0.0/16 to any via ${oif}
${fwcmd} add pass udp from 
200.204.151.121 to any keep−state
${fwcmd} add reject log all from 200.221.6.0/32 to any in via rl0
${fwcmd} add pass udp from any to any in via ${iif} keep−state

${fwcmd} add pass ip from any to any in via ${iif}
${fwcmd} add pass icmp from any to any
${fwcmd} add pass tcp from any to any established
${fwcmd} add pass tcp from any to any 49152−65535 in via ${oif}
${fwcmd} add pass tcp from any to any 113 in via ${oif}

${fwcmd} add pass tcp from any to any 22 in via ${oif}
${fwcmd} add pass tcp from any to any 22 via ${iic}
${fwcmd} add pass tcp from any to any 53 in via ${oif}
${fwcmd} add pass log tcp from any to any 25 in via ${oif}

# ${fwcmd} add pass tcp from any to any 110 in via ${oif}
${fwcmd} add pass udp from any to any 49152−65535 in via ${oif}
# ${fwcmd} add pass udp from any to any 53 in via ${oif}
${fwcmd} add deny log ip from any to any

#−−−−−>

Os colegas podem notar que algumas dessas regras foram tomadas ‘emprestadas’ do rc.firewall original, existente em /etc :-). A idéia é KISS :-), sempre que for possível. As demais regras são bem simples, uma vez que o propósito desta bridge é ser uma plataforma de testes, para ampliarmos nosso conhecimento em filtragem de pacotes aplicadas à bridges. Lógico, essas regras devem ser revisadas e estabelecidas de acôrdo com o melhor conhecimento de cada um dos colegas quanto às suas próprias necessidades, caso venha a ser colocada em produção.

Uso: entre um roteador qualquer e um cliente qualquer. Em topologia mais sofisticada, ficaria entre o roteador e um firewall qualquer, ou ainda entre um firewall qualquer e uma rede qualquer :-). Bem, sugiro experimentarem :-), à vontade.

log /var/log/security

Dec 21 21:07:17 infoway /kernel: ipfw: 2300 Deny TCP 192.168.10.10:1024
192.168.10.1:22 out via rl2
Dec 22 08:07:05 infoway /kernel: ipfw: limit 250 reached on entry 2300

Dec 22 23:01:52 infoway /kernel: ipfw: limit 250 reached on entry 2300
Dec 23 08:14:30 infoway /kernel: ipfw: limit 250 reached on entry 2300
Dec 23 08:58:25 infoway /kernel: ipfw: 3100 Accept TCP 
192.168.10.1:619
192.168.10.10:22 in via rl2
Dec 23 08:59:00 infoway /kernel: ipfw: 3100 Accept TCP 192.168.10.1:718

192.168.10.10:22 in via rl2
Dec 23 09:03:20 infoway /kernel: ipfw: 3100 Accept TCP 192.168.10.1:654
192.168.10.10:22 in via rl2
Dec 23 09:07:48 infoway /kernel: ipfw: 3100 Accept TCP 
192.168.10.1:1012
192.168.10.10:22 in via rl2
Dec 23 10:07:37 infoway /kernel: ipfw: limit 250 reached on entry 2300
Dec 23 14:11:21 infoway /kernel: ipfw: Accounting cleared.

Dec 23 15:07:30 infoway /kernel: ipfw: limit 250 reached on entry 2100
Dec 23 18:18:57 infoway /kernel: ipfw: 3100 Accept TCP 192.168.10.1:744

192.168.10.10:22 in via rl2
Dec 23 18:23:54 infoway /kernel: ipfw: 3100 Accept TCP 192.168.10.1:952
192.168.10.10:22 in via rl2
Dec 23 18:28:14 infoway /kernel: ipfw: 3100 Accept TCP 
192.168.10.1:736
192.168.10.10:22 in via rl2
Dec 23 19:28:07 infoway /kernel: ipfw: 3100 Accept TCP 192.168.10.1:758

192.168.10.10:22 in via rl2
Dec 23 19:36:24 infoway /kernel: ipfw: 3100 Accept TCP 192.168.10.1:665

192.168.10.10:22 in via rl2
Dec 23 19:37:25 infoway /kernel: ipfw: Accounting cleared.
Dec 23 19:40:26 infoway /kernel: ipfw: 3100 Accept TCP 192.168.10.1:982

192.168.10.10:22 in via rl2
Dec 23 19:49:19 infoway /kernel: ipfw: 3100 Accept TCP 192.168.10.1:686
192.168.10.10:22 in via rl2
Dec 23 20:48:00 infoway /kernel: ipfw: limit 250 reached on entry 2100

Dec 23 21:59:21 infoway /kernel: ipfw: 3100 Accept TCP 192.168.10.1:944
192.168.10.10:22 in via rl2
Dec 23 22:00:54 infoway /kernel: ipfw: 3100 Accept TCP 
192.168.10.1:734
192.168.10.10:22 in via rl2
Dec 23 22:01:06 infoway /kernel: ipfw: 3100 Accept TCP 192.168.10.1:905

192.168.10.10:22 in via rl2
Dec 23 22:07:30 infoway /kernel: ipfw: 3100 Accept TCP 192.168.10.1:928

192.168.10.10:22 in via rl2
Dec 23 22:07:49 infoway /kernel: ipfw: 3100 Accept TCP 192.168.10.1:985
192.168.10.10:22 in via rl2
Dec 23 22:12:21 infoway /kernel: ipfw: 3100 Accept TCP 
192.168.10.1:854
192.168.10.10:22 in via rl2
Dec 24 08:59:53 infoway /kernel: ipfw: limit 250 reached on entry 2100
Dec 24 11:57:56 infoway /kernel: ipfw: 3100 Accept TCP 
192.168.10.1:944
192.168.10.10:22 in via rl2
Dec 24 13:00:23 infoway /kernel: ipfw: limit 250 reached on entry 2200
Jan 6 10:08:25 infoway /kernel: ipfw: limit 250 reached on entry 2200

Jan 7 15:58:50 infoway /kernel: ipfw: limit 250 reached on entry 2200
Jan 7 20:12:50 infoway /kernel: ipfw: limit 250 reached on entry 2200

Ah sim, para acessar a máquina, basta estabelecer um ‘alias’ para sua placa convencional de rede, para a mesma rede 192.168.10.0 de rl2.

Exemplo: ifconfig eth0:0 192.168.10.1 up (sintaxe Linux)

Depois de terminado quaisquer trabalhos que tenha tornado isso necessário, basta remover o aliases e.. pronto, novamente invisível 🙂

Lógico, todos já puderam perceber que a bridge é completamente inacessível (ou não?) a partir das rl0 e rl1, uma vez que não há um ip agregado às mesmas. Isso torna bastante difícil que haja uma ‘invasão’ da mesma :-). Contudo, o impossível é apenas algo que ainda não descobrimos como fazer, portanto.. Não existe nada seguro sob o sol, exceto a Morte 🙂

Notas (quase) importantes

1 – Supôe-se que o leitor já tem instalado o FreeBSD em condições funcionais, ou que saiba fazê-lo sem problemas, ou seja, não se imagina que o usuário seja um completo leigo em FreeBSD. 2 – Não sou responsável por quaisquer danos ou perda de dados decorrentes das instruções contidas nêste artigo. O usuário deve usar estas instruções por sua conta e risco. 3 – Funciona aqui. Deverá funcionar aí. Se não funcionar aí, o problema é local, portanto, NÃO OFEREÇO SUPORTE a qualquer instalação que tenha estas instruções como base. Divirtam-se 🙂