O protocolo ARP (Address Resolution Protocol) é utilizado para mapear endereços IP-para-ethernet e é tão utilizado que é quase impossível encontrar redes que utilizem um outro mecanismo para mapear endereços IP-para-ethernet (por exemplo, o mapeamento estático).
quinta-feira, 29 de novembro de 2007
ARP e ARP Flux
terça-feira, 6 de novembro de 2007
Check Point SPLAT Quick Tips
1) Overlapping Encryption Domains
Quando um servidor Smart Center Server (SCM) é utilizado para gerenciar mais de um firewall Check Point, podem existir problemas com a sobreposição do domínio da VPN (Encryption Domain ou enc dom). Neste caso é necessário definir manualmente o enc dom para que não haja esta sobreposição que poderá gerar problemas quando for utilizado o acesso remoto via Secure Client. Para verificar quais os gateways possuem sobreposição, devemos utilizar o comando (no SPLAT):
[Expert@smc-mgmt]# vpn overlap_encdom
The objects fw-01 and fw-02 have overlapping encryption domains.
The overlapping domain is:
10.10.0.0 - 10.10.255.255
Para mais detalhes consultar o sk32252.
2) Pen Drive USB no SPLAT
Para montar um pen drive no Check Point SecurePlatform utilizar o procedimento:
[Expert@fw]# mkdir /mnt/usb
[Expert@fw]# modprobe usb-storage
[Expert@fw]# mount -t vfat /dev/sdb1 /mnt/usb
Enjoy!
sexta-feira, 19 de outubro de 2007
VPN Site-to-Site entre CheckPoint e Outros Fabricantes
Apesar de todos os fabricantes informarem que seus produtos estão de acordo com as especificações dos RFCs, na pŕatica as implementações dos protocolos variam de fabricante para fabricante.
Estas peculiaridades acabam impactando na interoperabilidade entre produtos e isso não deixa de ser verdade quando se quer configurar uma VPN entre CheckPoint e outros vendedores.
Muitos problemas na fase 2 ocorrem quando há configurações diferentes entre os gateways envolvidos no túnel VPN Site-to-Site. A curiosidade aqui é que o CheckPoint, por padrão, tenta efetuar supernetting sempre que possível das redes locais.
Por exemplo, se o encryption domain inclui duas subredes adjacentes, 172.30.32.0/22 e 172.30.36.0/22, o CheckPoint irá negociar uma única supernet: 172.30.32.0/21. Na hipótese do gateway remoto não ser da CheckPoint, a fase 2 pode não funcionar caso ele esteja esperando duas subredes (172.30.32.0/22 e 172.30.36.0/22) ao invés de uma única subrede (172.30.32.0/21).
Para resolver o problema de suppernetting, é possível configurar o CheckPoint para não utilizar a maior rede possível. Isso é feito configurando diretamente no SmartCenter Server:
# dbedit
Enter Server name (ENTER for 'localhost'):
Enter User Name: fwadmin
Enter User Password: abc123
Please enter a command, -h for help or -q to quit:
dbedit> modify properties firewall_properties
ike_use_largest_possible_subnets false
dbedit> update properties firewall_properties
firewall_properties updated successfully.
dbedit> quit
#
Após feitas as configurações aplique a política novamente e efetue os testes necessários na VPN. No próximo post irei detalhar como utilizar supernetting em VPNs CheckPoint mesmo que a funcionalidade de supernetting esteja desabilitada.
CheckPoint: Limpando a tabela de NATs
Em algumas versões do CheckPoint, principalmente as anteriores a NGX, há um bug no gerenciamento das entradas na tabela de NAT do firewall que faz com que ele não exclua as entradas dos NATs que não estão sendo mais utilizados. Segue abaixo um gráfico que demonstra exatamente este comportamento da tabela de NATs (gráficos de quantidade de entradas na tabela versus o tempo):
Acabar com este lixo de memória se resolve, na maioria das vezes, fazendo a reinicialização das paredes (Security Gateways), causando assim a indisponibilidade temporária do ambiente. Em situações de configurações de alta-disponibilidade (cluster ou failover) não fogem também a esta regra, visto que todas as paredes precisarão ser reinicidas simultanemente para que a tabela de NATs seja limpa.
Para tentar reduzir o tempo de indisponibilidade é possível utilizar um comando que limpa a tabela de NATs do firewall e que deve ser executado a partir dos Security Gateways (estejam em cluster ou não):
# fw tab -t fwx_alloc -x
Desta forma o impacto somente irá ocorrer para as conexões que possuem NAT e não para o tráfego global que passa pelo firewall.
terça-feira, 7 de agosto de 2007
NAT Traversal
NAT ou Network Address Translation é, de uma forma muito simples, a tradução do endereço IP. Esta tradução pode ocorrer por muitos motivos, mas principalmente para que estações utilizando endereçamento privado (RFC 1918) acessem à Internet. Dessa forma, se a estação 10.10.10.1 necessita acessar um servidor na Internet, então será necessário traduzir o endereço 10.10.10.1 para um endereço publicamente conhecido. Como os principais protocolos de transporte (no caso, TCP e UDP) utilizam o conceito de multiplexação através de portas de origem e destino, então podemos utilizar somente um endereço IP público para traduzir vários endereços privados (NAT masquerade ou NAT Hide), utilizando portas diferentes e armazenando todas estas informações em uma tabela de conexões.
Entretanto, o protocolo ESP (utilizado no IPSEC) não utiliza o mesmo conceito de portas utilizado nos protocolos TCP e UDP e, portanto, não é possível fazer a tradução de endereço e utilizar a informação de portas de origem e destino como forma de multiplexação das conexões. Para que uma conexão VPN funcione quando existe um equipamento fazendo NAT (Hide ou muitos-para-um) entre os pontos que estão estabelecendo a VPN é necessário que haja um mecanismo para garantir que os pacotes serão traduzidos adequadamente, desde a origem até o destino final. Este mecanismo é chamado de NAT Traversal.
De uma forma bem simples, o NAT Traversal primeiramente verifica se os dois equipamentos que estão estabelecendo a conexão possuem suporte para NAT Traversal, em seguida os dois equipamentos devem detectar se existe ou não a tradução de endereços. Por fim, deve-se negociar os parâmetros do protocolo (portas utilizadas para encapsulamento, utilização de cookies, etc) e em seguida iniciar a transmissão de dados utilizando pacotes encapsulados. Todo este processo esta descrito no RFC 3947 - Negotiation of NAT-Traversal in the IKE.
Este recurso pode ser utilizado com conexões VPN do tipo gateway-to-gateway ou client-to-gateway e deve ser verificado na documentação do equipamento se o mesmo suporta NAT Traversal ou UDP Encapsulation (expressão também utilizada por alguns fabricantes).
quinta-feira, 2 de agosto de 2007
Object Filler
Existe algum jeito de automatizar a criação de objetos no Check Point SmartDashboard? Sim, existe, mas não é utilizando o SmartDashboard. :-)
O Object Filler é um software escrito por Martin Hoz, funcionário da Check Point, que gera a partir de uma entrada padrão (arquivo com nomes e endereços, ACL de roteadores Cisco ou firewalls PIX, Juniper Netscreen, etc) scripts que podem ser utilizados no DBedit para automatizar uma tarefa que muitos vezes é árdua.
Vale também conferir o Tutorial que explica detalhadamente como funciona o Object Filler e o funcionamento básico do DBedit.
Object Filler/Object Dumper - 02/08/2007
segunda-feira, 16 de julho de 2007
Cisco PIX e TFTP
Apesar de ter uma interface muito parecida com o IOS, a configuração dos firewalls da Cisco (os famosos Cisco PIX) é em alguns casos muito diferente do IOS utilizado nos roteadores. Por exemplo, quando é necessário copiar uma configuração de um firewall para um servidor tftp e restaurar este backup em um outro firewall os comandos "copy runn tftp" e "copy tftp runn" não estão disponíveis no PIX.
Para fazer o backup da configuração atual de um firewall Cisco PIX (neste exemplo na versão 6.3(5)) para um servidor de tftp, devemos utilizar o comando:
pix1# write net 10.10.10.10:arquivo.cfgOnde 10.10.10.10 é o endereço IP do servidor tftp e arquivo.cfg é o nome do arquivo que será criado com o backup da configuração.
O processo inverso é um pouco menos trivial e, para isso, devemos utilizar o comando configure dentro da opção de configuração:
pix2# configure terminalApós entrar com o comando acima a configuração que foi salva no servidor de tftp será carregada no segundo pix.
pix2(config)# configure net 10.10.10.10:arquivo.cfg
terça-feira, 19 de junho de 2007
Exportar usuários do checkpoint
Para conseguir exportar os usuários VPN criados no checkpoint basta executar o comando abaixo.
Ele irá resultar em um arquivo CVS contendo a listagem dos usuários e seus atributos.
/$FWDIR/bin/fwm dbexport -f /path/aquivo.cvs
terça-feira, 27 de março de 2007
Portas para Acesso do Cliente VPN Check Point
Mesmo sendo muito simples instalar e configurar uma conexão VPN client-to-gateway utilizando o SecureClient ou SecuRemote da Checkpoint, podem haver diversos problemas de conexão entre o cliente e o gateway de VPN quando a comunicação passa através de um firewall (ou proxy) que não libera todo o acesso do cliente para o gateway de VPN. Ou seja, é necessário liberar as portas e protocols (do cliente para o gateway):
- TCP 264 (download da topologia)
- UDP 500 (IPSEC and IKE)
- IPSEC ESP (protocolo 50)
- IPSEC AH (protocolo 51)
- TCP 500 (se utilizada a opção "IKE over TCP")
- UDP 2746 ou outra porta(*) (se utilizada a opção "UDP encapsulation")
- FW1_scv_keep_alive (UDP port 18233) — SCV keep-alive packets
- FW1_pslogon_NG (TCP port 18231) or (TCP port 65524 for Application Intelligence) — SecureClient's login to Policy Server
- FW1_sds_logon (TCP port 18232) — SecureClient's Software Distribution Server (SDS) download protocol
- tunnel_test (UDP port 18234) — used by Check Point's Tunnel Test application
- RDP (UDP port 259) — Used in MEP's Proprietary Probing (PP) to discover available gateway
sexta-feira, 23 de fevereiro de 2007
Configurando Interfaces VLAN no FreeBSD
Quando trabalhamos com vlans, podemos segmentar a rede para diminuir o tráfego broadcast compartilhado e segmentar de forma que por exemplo tenhamos uma vlan por serviço/aplicação. A vantagem de ter um Freebsd com interfaces vlans seria, utilizar a mesma interface física para transportar varios tags (vlan id), excluindo a necessidade de uma placa de rede para cada segmento.
Configurando FreeBSD
Primeiramente necessitamos levantar o módulo if_vlan ou para quem queira deixar este suporte nativamente no kernel.
Para habilitar o suporte a vlans sem ter q recompilar o kernel utilizaremos o comando abaixo:
# kldload if_vlan
Não podemos esquecer de adicionar a entrada if_vlan_load=”YES” no arquivo /boot/loader.conf
Caso você queira compilar o suporte nativamente, adicione a entrada abaixo no seu arquivo de configuração e recompile o seu kernel:
device vlan
Depois do suporte a int vlans estar habilitado, vamos começar a configuração no Freebsd.
Vamos utilizar 4 tags para a nossa configuração, 5, 10, 15 e 20, para facilitar vamos associar o tag ao nome da interface vlan, tag 5 (vlan5), tag 10 (vlan10), tag 15 (vlan15), tag 20 (vlan20).
Criando as interfaces:
# ifconfig vlan5 create
# ifconfig vlan10 create
# ifconfig vlan15 create
# ifconfig vlan20 create
Apenas para conferir se as interfaces foram criadas
# ifconfig
A saída deverá ser algo como mostrado abaixo:
vlan5: flags=8002 mtu 1500
ether 00:00:00:00:00:00
vlan: 0 parent interface:
vlan10: flags=8002 mtu 1500
ether 00:00:00:00:00:00
vlan: 0 parent interface:
vlan15: flags=8002 mtu 1500
ether 00:00:00:00:00:00
vlan: 0 parent interface:
vlan20: flags=8002 mtu 1500
ether 00:00:00:00:00:00
vlan: 0 parent interface:
Nossas interfaces ja estão criadas, agora vamos associa-las ao devido tag e a interface física.
OBS: não é necessario a nome da int vlan ter o mesmo tag, por exemplo, pode ser criado a interface vlan0 e associado qualquer tag, criamos a vlan5 associada ao tag 5 para ficar mais fácil de coomprender.
Associando os tags:
# ifconfig vlan5 vlan 5 vlandev em0
# ifconfig vlan10 vlan 10 vlandev em0
# ifconfig vlan15 vlan 15 vlandev em0
# ifconfig vlan20 vlan 20 vlandev em0
Pronto, os tags ja estao devidamente configurados e associados a interface física em0.
Agora, atribua os endereços ips nas interfaces vlans.
# ifconfig vlan5 192.168.5.1 netmask 255.255.255.0 up
# ifconfig vlan10 192.168.10.1 netmask 255.255.255.0 up
# ifconfig vlan15 192.168.15.1 netmask 255.255.255.0 up
# ifconfig vlan20 192.168.20.1 netmask 255.255.255.0 up
A saída do ifconfig ficará como mostrado abaixo:
vlan5: flags=8843 mtu 1500
inet 192.168.5.1 netmask 0xffffff00 broadcast 192.168.5.255
inet6 fe80::203:47ff:fe07:63ff%vlan20 prefixlen 64 scopeid 0xb
ether 00:0a:5e:53:f8:ec
media: Ethernet autoselect (100baseTX )
status: active
vlan: 5 parent interface: em0
vlan10: flags=8843 mtu 1500
inet 192.168.10.1 netmask 0xffffff00 broadcast 192.168.10.255
inet6 fe80::203:47ff:fe07:63ff%vlan20 prefixlen 64 scopeid 0xb
ether 00:0a:5e:53:f8:ec
media: Ethernet autoselect (100baseTX )
status: active
vlan: 10 parent interface: em0
vlan15: flags=8843 mtu 1500
inet 192.168.15.1 netmask 0xffffff00 broadcast 192.168.15.255
inet6 fe80::203:47ff:fe07:63ff%vlan20 prefixlen 64 scopeid 0xb
ether 00:0a:5e:53:f8:ec
media: Ethernet autoselect (100baseTX )
status: active
vlan: 15 parent interface: em0
vlan20: flags=8843 mtu 1500
inet 192.168.20.1 netmask 0xffffff00 broadcast 192.168.20.255
inet6 fe80::203:47ff:fe07:63ff%vlan20 prefixlen 64 scopeid 0xb
ether 00:0a:5e:53:f8:ec
media: Ethernet autoselect (100baseTX )
status: active
vlan: 20 parent interface: em0
Nossas configurações já estão prontas, todas as int vlans configuradas com as tags associadas e com a interface física fxp0 devinida.
Agora vamos colocar nossas configurações no rc.conf para nao perde-las quando o FreeBSD for rebootado.
Adicionar no arquivo /etc/rc.conf as entradas abaixo:
cloned_interfaces="vlan5 vlan10 vlan15 vlan20"
ifconfig_vlan5="inet 192.168.5.1 netmask 255.255.255.0 vlan 5 vlandev em0"
ifconfig_vlan10="inet 192.168.10.1 netmask 255.255.255.0 vlan 10 vlandev em0"
ifconfig_vlan15="inet 192.168.15.1 netmask 255.255.255.0 vlan 15 vlandev em0"
ifconfig_vlan20="inet 192.168.20.1 netmask 255.255.255.0 vlan 20 vlandev em0"
Nossa configuração está concluída no lado do FreeBSD, vou colocar a configuração que deve ser realizada switchs Cisco Catalyst 3750.
Logue no switch com seu usuário e senha, entre em modo enable:
Switch# enable
Defina uma porta onde será conectado o FreeBSD com as interfaces vlans, no nosso exemplo vamos escolher a porta Gi1/0/1.
Entre em como de configuração
Switch# configure terminal
Switch (config)# interface Gi1/0/1
Lembrando que a interface pode variar conforme o modelo do switch.
Switch (config-if)# switchport trunk encapsulation dot1q
Switch (config-if)# switchport mode trunk
Switch (config-if)# switchport trunk allowed vlan 5,10,15,20
Switch (config-if)# description “DESCRIÇÃO DA PORTA”
Com estas configurações na porta estamos deixando trafegar apenas as vlans 5, 10, 15 e 20, caso queira adicionar mais uma vlan no trunk do switch, utilize o comando abaixo:
Switch (config-if)# switchport trunk allowed vlan add 25
Adicionamos a vlan 25 na porta Gi1/0/1 do switch.
Configure o restante das portas do switch em mode access conforme mensionado abaixo:
Switch (config-if)# interface Gi1/0/2
Switch (config-if)# switchport mode access
Switch (config-if)# switchport access vlan 5
Com isso a porta dois consequirá conversar com a interface vlan 5 do FreeBSD através da porta 1 do switch que esta configurada em mode trunk. Faça o mesmo com as outras portas definindo a vlan que deve ser acessada pela porta.
Com isto finalizamos nosso how-to, este tipo de configuração normalmente é utilizado em firewalls, faça um cálculo de tráfego para não ter gargalo físico na placa de rede, se o tráfego for grande em cada vlan utilize uma placa Gigabit de boa qualidade.
segunda-feira, 15 de janeiro de 2007
Greylisting usando spamd (OpenBSD) em modo bridge - Parte 2
A princípio, pode assustar (principalmente o particionamento :) ), mas, prometo que agora será mais leve!
Vamos à configuração do nosso greylisting.
Primeiramente, precisamos habilitar o sistema operacional a repassar pacotes de uma interface para a outra, e, além disso, habilitar a ativação do packet filter no boot.
Edite o /etc/sysctl.conf e descomente a seguinte linha:
net.inet.ip.forwarding=1 #1=Permit forwarding (routing) of packets
Edite também o arquivo /etc/rc.conf e adicione a seguinte linha:
pf=YES #Enable PF
Agora, partiremos para a configuração da Bridge.
Para cada interface de rede, é necessário criar um arquivo de configuração. Para a interface xl0, que será ligada à Internet, crie o arquivo /etc/hostname.xl0 . Edite o arquivo e adicione o seguinte (lembre-se o que combinamos no post anterior: no lugar dos IPs representados por letras deve ser usado um IP válido na Internet):
inet aaa.bbb.ccc.ddd 255.255.255.0 NONE
O IP usado na interface externa (xl0) deve pertencer à mesma sub-rede dos seus servidores de e-mail.
Agora para a interface xl1, crie o /etc/hostname.xl1 e adicione no arquivo:
inet 192.168.10.10 255.255.255.0 NONE
E, na interface xl2, crie o /etc/hostname.xl2 e adicione no arquivo:
inet 192.168.10.11 255.255.255.0 NONE
Agora, devemos colocar todas estas interfaces como parte da bridge. Para isso, crie o arquivo /etc/bridgename.bridge0 e adicione o seguinte:
add xl0
add xl1
add xl2
up
Agora, é necessário configurar o spamd. Para isso, edite o arquivo /etc/rc.conf e habilite as seguintes configurações:
spamd_flags="-v -G 25:4:864" #para entender esses números, leia o manual do spamd (man spamd)
spamd_grey=YES # use spamd greylisting if YES
spamlogd_flags="" # use eg. "-i interface" and see spamlogd(8)
O spamd pode consultar listas públicas onde são cadastrados domínios que já enviaram Spam. Isso pode ser configurado no arquivo /etc/spamd.conf . Eu nunca testei essas consultas pois faço isso em outro momento no sistema. Minha configuração é a seguinte:
all:\
:blacklist:whitelist:
whitelist:\
:white:\
:method=file:\
:file=/etc/whitelist.conf:
blacklist:\
:black:\
:msg="SPAM. Your address %A is blocked":\
:method=file:\
:file=/etc/blacklist.conf:
É muito importante que você leia o manual do spamd.conf e entenda o que quer dizer cada linha desta, e, principalmente, como estas listas branca e negra se anulam. Basicamente, nesta configuração, estou dizendo em qual arquivo estão os IPs que não precisam ser filtrados (whitelist) e em qual arquivo estão os IPs dos quais não quero receber e-mail de maneira alguma (blacklist). Mesmo que não os utilize, crie os arquivos whitelist.conf e blacklist.conf
touch /etc/whitelist.conf
touch /etc/blacklist.conf
Agora, a parte mais divertida e elaborada desta implementação: a configuração do pf! Adianto que ela não foi desenvolvida por mim, mas sim por Graham Toal, da Universidade do Texas. O link onde ele disponibilizou isso não está mais no ar. Portanto, coloco aqui para prosperar a criação de Graham (que não é o Bell, mas sim o Toal. Thanks Graham! (os dois!) ). Enfim, fiz apenas algumas pequenas adaptações para facilitar o entendimento do arquivo, o qual está a seguir. Edite o /etc/pf.conf e copie para lá a seguinte configuração, adaptando para o seu cenário. Vou configurar o arquivo de acordo com o nosso:
# $OpenBSD: pf.conf,v 1.29 2005/08/23 02:52:58 henning Exp $
#
# See pf.conf(5) and /usr/share/pf for syntax and examples.
# Remember to set net.inet.ip.forwarding=1 and/or net.inet6.ip6.forwarding=1
# in /etc/sysctl.conf if packets are to be forwarded between interfaces.
#variaveis
ext_if="xl0" #ligada a Internet
int_if= "{ xl1, xl2 }" #interfaces da maquina. Temos tres: uma para entrada da internet
# e outras duas para ligar cada um dos dois MX's.
ip_local="aaa.bbb.ccc.ddd" #esse é o ip pelo qual você consegue conectar na bridge
mail_server= "{ eee.fff.ggg.hhh, iii.jjj.kkk.lll }" #IPs dos MXs que estao atrás da brigde
#Maquinas ou redes da sua instituicao permitidas a acessar servicos no $mail_server
ip_snmp= "{ xxx.xxx.xxx.xxx, xxx.xxx.xxx.xxx }" #esses IPs podem ter aceso à porta SNMP dos #$mail_server
ip_ssh= "{ xxx.xxx.0/24, xxx.xxx.xxx.0/24, xxx.xxx.xxx.0/24 }" #IPs podem ter acesso à porta SSH #dos $mail_server
#Tabelas usadas em conjunto com o spamd
table < spamd > persist file "/etc/blacklist.conf"
table < spamd-white > persist
table < whitelist > persist file "/etc/whitelist.conf"
set block-policy drop
#Aumentar o limite de entradas nas tabelas (Padrao: 100000)
set limit table-entries 500000
scrub on $ext_if reassemble tcp no-df random-id
# testes de redirecionamento para o spamd
# Está na whitelist? - Então passe sem ser tocado
no rdr on $ext_if \
inet \
proto tcp \
from < whitelist > \
to any
# Se chegou aqui, não está em whitelist. Está na blacklist?
# Redireciono para o spamd, o qual vai "gastar o tempo" do spammer
# e no final da "interação smtp" dirá que ele está na blacklist
rdr on $ext_if \
inet \
proto tcp \
from < spamd >\
to any \
port smtp -> 127.0.0.1 port spamd
# ainda não está na tabela dinâmica spamd-white
# redireciono para o spamd que vai tratar a mensagem
rdr on $ext_if \
inet \
proto tcp \
from !< spamd-white > \
to any \
port smtp -> 127.0.0.1 port spamd
#bloquear tudo por padrão
block in all
block out all
#libera conexao do localhost para porta de configuracao do spamd 8026
pass in quick proto tcp from 127.0.0.1 to 127.0.0.1 port 8026
#liberar ICMP
pass in quick on $ext_if proto icmp from any to any
#liberar SSH para IPs contidos nas variáveis
pass in quick on $ext_if proto tcp from $ip_ssh to $mail_server port 22 keep state
pass in quick on $ext_if proto tcp from $ip_ssh to $ip_local port 22 keep state
#SNMP
pass in quick on $ext_if proto udp from $ip_snmp to $mail_server port 161 keep state
pass in quick on $ext_if proto tcp from $ip_snmp to $mail_server port 161 keep state
pass in quick on $ext_if proto udp from $ip_snmp to $ip_local port 161 keep state
pass in quick on $ext_if proto tcp from $ip_snmp to $ip_local port 161 keep state
# permitir especificamente os pacotes que foram redirecionados acima
pass in quick on $ext_if \
inet \
proto tcp \
from < whitelist > \
to port smtp
# Pacotes permitidos passam diretamente para o mail_server
# ou seja, já estão na tabela dinâmica spamd_white
pass in quick on $ext_if \
inet \
proto tcp \
from < spamd-white > \
to port smtp
pass in on $ext_if \
route-to lo0 \
inet \
proto tcp \
from any \
to 127.0.0.1 \
port spamd
pass out quick on $ext_if \
inet \
proto tcp \
from $ext_if \
to any \
port smtp \
flags S/SA \
keep state
pass out quick on $int_if \
inet \
proto tcp \
from $int_if \
to any \
port smtp \
flags S/SA \
keep state
pass out keep state
pass quick on { lo xl0 xl1 xl2 } #nomes das interfaces. Adapte para sua configuracao.
#Mantenha lo
antispoof log quick for { lo xl0 xl1 xl2 } #nomes das interfaces. Adapte para seu caso.
#Mantenha lo
Agora, é necessário ativar a atualização da tabela do pf pelo spamd, adicionando uma entrada no crontab. Para isso, como root, faça o seguinte:
#crontab -e
E, no arquivo, adicione as linhas:
#atualizacao spamdb
5 * * * * /usr/libexec/spamd-setup
Esta é toda a configuração necessária. Reinicie a máquina para que elas "entrem em vigor"! :D
Agora, antes de colocar em produção, faça testes enviando e-mail de fora da sua rede. Diminua os tempos configurados no /etc/rc.conf para que seu teste não demore muito (ao invés de 25 minutos como coloquei, coloque 1 minuto. Não use o valor de 1 minuto em produção. Será pouco efetivo. Eu utilizo estes valores que mostrei).
Dicas de comandos úteis
Leia os seguintes manuais
- man spamd
- man spamd-setup
- man spamdb
- man spamd.conf
Comandos do pf
- Adicionar endereço IP na tabela spamd-white:
pfctl -t spamd-white -T add xxx.yyy.zzz.www
- Ver as regras carregadas:
pfctl -s rules
- Testar o arquivo pf.conf antes de carregá-lo
pfctl -nf /etc/pf.conf
- Carregar o arquivo de configuração /etc/pf.conf
pfctl -f /etc/pf.conf
Boa sorte nas configurações! Torço para que seja útil!
Greylisting usando spamd (OpenBSD) em modo bridge - Parte 1
Greylisting é uma técnica usada para combater o Spam, que, atualmente, funciona bem para diminuir o número de propagandas não solicitadas, phishings e vírus na caixa de entrada de e-mail dos usuários. Digo atualmente porque, não tenho dúvidas, que os spammers vão se adaptar a esta técnica. Mas não desanime! Essa é apenas mais uma camada das muitas já implementadas na segurança do seu sistema! :D
Esta técnica se aproveita do fato que, geralmente, os spammers utilizam programas para envio de e-mails em massa ou proxies smtp mal configurados que, ao contrário do que prevê o RFC 821 [1], não reenviam os e-mails caso recebam uma mensagem de falha temporária. Assim, o greylisting exige que uma mensagem seja enviada 1 vez, para que entre na greylist, e, após o tempo mínimo de espera para reenvio configurado no software que fará esse controle de greylisting, mais duas vezes, para que então seja entregue. Uma explicação excelente e didática do funcionamento desta técnica pode ser lida em [2] .
A abordagem que será descrita aqui é útil para que você não precise mudar nada em seu servidor de e-mails. Portanto, caso ele não tenha algum suporte para esta técnica, isso não será problema. O que teremos será uma "caixa preta" que fará todo o controle dos e-mails que chegam aos seus MX (mail exchanger). Todo e-mail que chegar ao MX certamente terá passado pela filtragem do Greylist.
Será necessário um computador com tantas placas de rede quanto forem seus MX mais uma, ligada à internet (Exemplo: Tenho 2 MXs, portanto, precisarei de 3 placas de rede).
Antes de tudo, instale as placas no computador e o sistema operacional OpenBSD (isso foge do escopo deste texto. Vide [3]). Feito isto, mais uma pequena explicação sobre como funcionará o greylisting, agora, utilizando esta implementação.
O greylisting funcionará utilizando a interação entre o daemon spamd (que fará o controle dos e-mails) e o pf (packet filter, o firewall do OpenBSD [4]). O spamd fará o controle do banco de dados citado na referência 2 e atualizará a tabela do packet filter segundo o banco de dados. Ou seja, o IP (fictício) 10.1.2.3 já passou pelos testes e está apto a entregar mensagens no MX, portanto, ele adicionará esse IP na tabela do PF que libera a passagem de pacotes originados deste IP à porta 25. Na próxima vez que este IP enviar e-mails para os meus MXs, o PF verá em suas tabelas que o IP está liberado e permitirá que o pacote siga para o MX correto. Caso um IP não esteja liberado em sua tabela ainda, o PF redirecionará o pedido para o daemon spamd. Este irá responder no lugar do MX (utilizando IP do MX para o qual a mensagem está sendo enviada), como se fosse um servidor SMTP. Pegará os dados, gravará na base de dados e retornará uma falha temporária. Quando for reenviado, checará se o tempo mínimo para reenvio foi satisfeito (digamos, depois de 25 minutos) e, se sim, coloca este IP na whitelist e retorna um erro temporário. Avisa o PF que este IP está liberado, e, no próximo reenvio, o pacote passará pela bridge e chegará de fato ao MX. Agora, vamos às configurações.
Consideremos que o computador tenha três placas: xl0, xl1 e xl2. Consideremos ainda que a placa xl0 será ligada à Internet e as outras duas a cada um dos meus MXs (lembre-se que, para ligar um computador diretamente ao outro, deve-se usar um cabo cross UTP, considerando que está usando uma placa Ethernet com conector RJ-45 :) ). O cenário está ilustrado a seguir (considere os IPs representados com letras IPs válidos na Internet):

Assim que terminar, volte ao blog para começarmos as configurações! Até logo!
[1] http://www.ietf.org/rfc/rfc0821.txt
[2] http://www.antispam.br/admin/greylisting/
[3] http://www.openbsd.org/faq/faq4.html
[4] http://www.openbsd.org/faq/pf/
terça-feira, 2 de janeiro de 2007
PIX - Conectar via SSH
Para se conectar ao PIX via SSH, além de habilitar as conexões via o protocolo é preciso criar uma chave RSA no equipamento. Para isso basta seguir os comandos abaixo.ca generate rsa key 1024Sem esses comandos, a cada vez que o equipamento é reinicializado será preciso abrir a interface gráfica via HTTPS para que ele gere essa chave.
ca save all
write memory
sexta-feira, 22 de dezembro de 2006
Checkpoint Troubleshooting
Muitas vezes nos deparamos com alguns problemas difíceis de se diagnosticar somente com o SmartView Tracker (Logs das regras). Isso porque, nestas vezes, também nos deparamos com Firewalls de grande capacidade (leia-se: muito tráfego).
Existem dois procedimentos que podem ajudar no caso descrito acima:
1) Utilizar o fw monitor para capturar os pacotes e analisar onde está o problema. Este procedimento ajuda a encontrar problemas de tradução de endereços (NAT) e de regras erradas (drop verus accept, ordenação das regras, etc).
A utilização do fw monitor é descrita neste documento. Este documento é importante para entendermos como os pacotes são tratados nas filas de inbound/outbound e como interpretar as direções pré-estabelecidas (i: pre-In; I: post-In; o: pre-Out; O: post-Out). Exemplo de utização do fw monitor:
[Expert@cpmodule]# fw monitor -e "accept ((src=10.10.10.1) or (dst=172.16.0.1));" -o arquivo.cap
É possível também utilizar um Ethereal - atualmente Wireshark - modificado (chamado CPEthereal, disponível no web site do Checkpoint) para ler a captura de pacotes (arquivo.cap) de forma mais intuitiva e com algumas facilidades para o formato do fw monitor.
2) Outro procedimento que podemos utilizar para ajudar no diagnóstico de pacotes que são bloqueados pelo Firewall é o comando abaixo:
[Expert@cpmodule]# fw ctl zdebug drop > drops.txt
Deixe o programa executar por algum tempo (com tráfego passando pelo Firewall); após este período entrar com o comando Ctrl+C e no arquivo drops.txt existirá uma série de entradas com os pacotes que foram bloqueados pelo Firewall.
