A Checkpoint divulgou este mês uma vulnerabilidade no software cliente de VPN Checkpoint SecureClient/SecuRemote relacionada com a opção "Auto Local Logon" que armazena as informações de login do usuário no registro do Windows (HKLM\Software\Checkpoint\SecuRemote) sem configurar adequadamente as permissões de leitura e escrita, permitindo que qualquer usuário do sistema consiga acessar (e posteriormente usar) as informações de login do usuário. Os sistemas afetados são VPN-1 SecuRemote/SecureClient NGX R60 e NG-AI R56 para a plataforma Microsoft Windows. A Checkpoint já disponibilizou um update que corrige este problema.
- Mais informações na página oficial do suporte Checkpoint ou no release notes do SecuRemote/SecureClient Supplement 2 que corrige este problema.
quarta-feira, 13 de fevereiro de 2008
Vulnerabilidade no Checkpoint SecureClient
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.
segunda-feira, 2 de abril de 2007
VPN Cisco e MTU
O padrão para interfaces Ethernet é de 1518 bytes já contando os cabeçalhos de camada 2. No entanto quando se usa um túnel VPN esse MTU diminui devido aos cabeçalhos adicionais de criptografia (este MTU pode variar dependendo do algoritmo utilizado).
Quando um roteador Cisco tenta passar um pacote maior do que o túnel VPN permite ele manda uma mensagem ICMP unreachable para o originador do pacote informando qual o novo MTU. Portanto é importante permitir que o roteador envie as mensagens de ICMP unreachable com o seguinte comando nas interfaces inside e outside do túnel VPN.
conf t
int fas 0/0
ip unreachables
int fas 0/1
ip unreachablesPara descobrir qual o maior MTU permitido em um determinado caminho podem ser utilizados os seguintes comandos:
traceroute -M -I icmp dest_ip_addr
ou
tracepath -n dest_ip_addr
Maiores informações em:
http://www.cisco.com/en/US/products/ps6350/products_configuration_guide_chapter09186a0080435c3e.html#wp1049788
http://www.cisco.com/en/US/products/ps6350/products_configuration_guide_chapter09186a0080435c3e.html#wp1051721
