Como habilitar SCP no SPLAT (SecurePlatform)

Quem um dia precisou fazer uma cópia usando o scp de um servidor SPLAT e se deu conta que não era possível?

Bom nesse artigo vou mostrar 2 passos para habilitar copia de arquivos via SCP no SPLAT:

1 – Abra o arquivo /etc/passwd e modifique a linha em negrito

[Expert@cpmodule]# vi /etc/passwd
admin:x:0:0::/home/admin:/bin/cpshell -> modifique o shell padrão por /bin/bash admin:x:0:0::/home/admin:/bin/bash
: x!

Salve o arquivo

2 – Crie o arquivo /etc/scpusers e adicione o usuário admin neste arquivo:

[Expert@cpmodule]# vi /etc/scpusers
admin
: x!

Pronto, seu servidor SPLAT ja está pronto para receber conexões SCP.

 

 

Listando qual VLAN está em qual contexto de um firewall VSX

Em um firewall ASA com multiplos contextos você pode achar qual VLAN está associada com qual contexto com esses comandos:
changeto system
show context (esse comando mostrará a lista de contextos e as VLANs associadas a cada um deles)

Como obter a mesma informação em um firewall VSX?

Em um firewall VSX você pode usar o comando “cat /proc/net/vlan/config” para ver uma lista de todas as VLANs que estão configuradas no firewall.

Agora, como saber qual VLAN está em qual contexto? Se você tem muitos contextos essa pode ser uma tarefa trabalhosa.

Para resolver essa questão fizemos um shell script que mostra qual VLAN está em qual contexto de firewall.

Basta executar o script abaixo:

for x in `fw vsx stat -v | tr -d ” ” | grep ^[0-9] | cut -d ‘|’ -f 1`; do
echo “context # $x” >> contexts.txt;
fw getifs -vs $x >> contexts.txt;
done

Depois é só ver o resultado listando o conteúdo do arquivo contexts.txt: “cat contexts.txt”

O conteúdo do arquivo deve ser parecido com esse:

context # 1
localhost eth0.700 4.4.6.101 255.255.0.0
localhost eth0.701 4.4.5.101 255.255.0.0
localhost eth1.702 2.2.2.1 255.255.254.0
localhost eth1.703 3.3.3.1 255.255.254.0

Nesse caso nós temos as VLANs 700 e 701 na interface eth0 do contexto 1 e as VLANs 702 e 703 na interface eth1 do contexto 1.

NTP e VRRP no IPSO

É recomendável usar NTP com VRRP ou IP Clustering?
Baseado nas soluções: sk40322 e sk41502
Aplicável à: IPSO

* Muitas vezes é um requerido de um firewall em um ambiente de produção ter timestamps corretamente configurados com NTP.

* Sincronização de horário é recomendado para soluções de cluster.

Solução:

Quedas frequentes do serviço xntpd podem ser associadas com transições de VRRP e problemas de IP Clustering.

Nesses casos é prudente desabilitar o uso do NTP como servidor ou cliente, e ao invés disso usar o Agendador de Tarefas “Job Scheduler” para executar ntpdate, numa base diária ou mais frequente. A causa mais comum de quedas do xntpd é a mudança de estado em interfaces como link up/down, buffers cheios etc. Não há desvantagem alguma em executar o ntpdate ao invés do ntp.

Como ajustar o intervalo de consuta no NTP

Na maioria das plataformas Unix você pode editar o arquivo ntp.conf e especificar os parametros minpoll/maxpoll. Um minpoll ou maxpoll de n significa que ele vai, no mínimo, consultar o servidor ntp a cada 2n segundos.

O IPSO não provê um mecanismo para controlar com qual frequência ele consultará o NTP. No entanto, você pode desabilitar o NTP e chamar o comando ntpdate periodicamente usando um cron job. Esse comando consulta um servidor NTP espedificado e atualiza o horário no sistema local.

Examplo:
Se você desabilitar o NTP e quer atualizar o horário uma vez por dia com o servidor NTP 10.9.8.1 às 00:15, siga esses passos:

No Voyager, clique em “System -> Configuration -> System Configuration -> Job Scheduler”.
Complete os campos com essa informação:
Job Name: ntp
Command: /usr/sbin/ntpdate 10.9.8.1 (Obs: Você deve sempre usar o caminho completo para o comando)
Timezone: Local
Repeat: Daily

Clique em “Apply”

Na seção “Execution Detail” preencha os campos com esssa informação:
Hour: 0
Minute: 15

Clique em “Apply” e “Save”.

Obs: devido a uma limitação do Voyager, não é possível usar o “Job Scheduler” para agendar qualquer tarefa para ocorrer com uma frequência maior do que uma vez por dia. Não é necessário atualizar o horário com ntpdate mais do que uma vez por dia.

Como evitar o IPS/Web Intelligence para hosts específicos

Baseado na solução:  sk31918
Aplicável à:   R70, NGX R65, R71, R75

Sintomas

Mensagem de erro “Invalid lf-cr combination in the http header” no SmartView Tracker.
Tráfego para a porta 80 é bloqueado com a mensagem de erro mostrada acima quando o Worm Catcher está habilitado.
Esse erro aparece para tráfego HTTP normal e para tráfego que não é HTTP e está usando a porta 80.

Causa

O módulo Web Intelligence traz algumas proteções, tais como o Worm Catcher e cabeçalhos de resposta ASCII-only, e isso implica que o tráfego precisa estar em conformidade com as RFCs do protocolo HTTP. Há verificações adicionais de segurança habilitados que não são explicitamente mencionados nas opções do IPS/Web Intelligence.

Solução

Cuidado: Se você aplicar a solução descrita a seguir, os endereços IP especificados, as portas e protocolos não serão inspecionados pelo IPS/Web Intelligence.

Continuar lendo

Como migrar a tabela de roteamento de um firewall SPLAT ou Linux com iproute2

No sistema antigo siga os seguintes passos:

Execute o comando: ip route show | grep via

Copie a saída do comando para um arquivo ou redirecione-a para um arquivo adicionando “> rotas.txt” ao comando anterior

Revise a lista e verifique se ela contem todas as rotas que você precisa. Caso haja rotas desnecessárias você pode deletá-las removendo a linha inteira.

Adicione “ip route add” no começo de cada linha usando um editor de texto da sua escolha ou usando esse comando a seguir:
cat rotas.txt |awk ‘{ print “ip route add “$0 ; }’ > rotas_para_importar

As linhas no arquivo rotas_para_importar devem se parecer com essas:
ip route add 10.1.1.1 via 192.168.10.1 dev eth0
ip route add default via 192.168.10.102 dev eth0

Execute o arquivo (sh rotas_para_importar) no sistema de destino. As rotas serão adicionadas à tabela de roteamento.

Para fazer as rotas sobreviverem a um reboot use esses comandos no SPLAT:

save_route –save ou cpnetconf store

Em um sistema Linux comum você deve executar o arquivo rotas_para_importar no final da inicialização do sistema. Por exemplo no Slackware você deve adicionar essa linha “/caminho/para/rotas_para_importar” no arquivo /etc/rc.d/rc.local, já no Ubuntu essa linha pode ser adicionada em /etc/rc.local. Esse arquivo varia em cada distribuição.

Guia de referência fw monitor

Este comando permite que você monitore o tráfego de rede passando através do modulo de Kernel do Firewall. Também mostra a você como o tráfego deve parecer na perspectiva de várias partes de um Firewall e pode monitorar todas as interfaces simultaneamente. É muito importante salientar que o comando fw monitor não funciona na camada 2, ou seja, não é possível capturar endereços MAC com o fw monitor. O fw monitor funciona em qualquer plataforma onde o software Check Point estiver instalado.

Uso:

fw monitor [-d] [-D] -e inspect-filter -f filter-file [-l len] [-m mask] [-x offset[,len]] [-o file]

Nota: SecureClient contém o comando srfw dentro de C:\Program Files\CheckPoint\SecuRemote que também funciona como fw monitor (e.g. srfw monitor).

Existem quatro “pontos de inspeção” quando um pacote passa através de um firewall Check Point (Security Gateway). Nós escolhemos onde queremos ver os pacotes com a opção -m:

    Antes que o firewall processe o pacote na  direção de entrada (i ou PREIN)

    Depois que o firewall processe o pacote na  direção de entrada (I ou POSTIN)

    Antes que o firewall processe o pacote na  direção de saída (o ou PREOUT)

    Depois que o firewall processe o pacote na  direção de saída (O ou POSTOUT)

Continuar lendo

Adicionando rotas estáticas no SPLAT usando sysconfig

Para adicionar rotas estáticas no SPLAT – SecurePlataform siga esses passos:

Apartir do console no SPLAT ou em uma janela de terminal, execute o comando: sysconfig.

1. Escolha a opção ‘Routing’.

2. Escolha se você quer adicionar uma nova rota de rede (Add new network route) ou uma nova rota de host (Add new host route).

3. Preencha essas informações:
a. Endereço IP da rede ou do host. Máscara de rede (não se aplica a rotas de host).
b. Endereço IP do gateway.
c. Interface de saída (essa é a interface do firewall para onde os pacotes serão roteados, isto é, a interface usada para chegar no gateway dessa rota).

As rotas serão salvas automáticamente assim que forem adicionadas.

4. Escolha a opção ‘Exibir a Configuração de Roteamento’ (Show Routing Configuration) para verificar se as rotas foram realmente adicionadas.

5. Escolha ‘Done’ e então ‘Exit’ para sair do sysconfig.

Baseado na solução sk21474.
Se aplica à NG, NGX R60, NGX R61, NG AI.

Como adicionar e salvar rotas no SPLAT sem usar as ferramentas ‘sysconfig’ ou ‘webui’

A sintaxe para adicionar rotas em um firewall CheckPoint rodando SPLAT pela linha de comando (CLI) é a seguinte:

ip route add <IP/SUBNET> via GW

Obs: Esse comando funciona em qualquer distribuição Linux que tenha o pacote iproute2 instalado. O pacote iproute2 deve subistituir as ferramentas clássicas “ifconfig”, “route” e “arp”.
Continuar lendo

CST – Configuration Summary Tool

A ferramenta de sumário de configuração (CST – Configuration Summary Tool) do IPSO é um script localizado no diretório /etc, ela cria um arquivo de sumário da configuração atual do seu sistema operacional IPSO no formato HTML.

O CST está incluído no IPSO 3.8 build 20 e em todos as versões e atualizações subsequentes do IPSO. Se você está executando uma versão do IPSO que seja inferior à IPSO 3.8 build 20, você pode fazer o download do CST nesse link: CST Versão 02-24-04g para IPSO 3.5 até IPSO 3.8.

O IPSO 6.1 e versões superiores inclue uma ferramenta chamada ECST, que é uma versão melhorada desta ferramenta. Essa ferramenta também está disponível separadamente para o IPSO 4.1 e 4.2. Veja o artigo em inglês sk39913 – Enhanced Configuration Summary Tool (ECST) para mais informações.
Continuar lendo

Proxy-Arp: O que é e como funciona

O Proxy-arp é um método onde um determinado host, que pode ser um router ou firewall por exemplo, responde um arp request em nome de outro host. Este protocolo (RFC-1027 http://www.ietf.org/rfc/rfc1027.txt) foi desenvolvido no final dos anos 80 pelo Departamento de Ciências da Computação da Universidade do Texas em Austin por necessidade deste em segmentar sua rede de computadores. Porém, naquela época, nem todos os devices de rede podiam ter seus endereços de redes subnetados, ou seja, um endereço classe A não poderia ser dividido em duas, três, doze, etc … redes diferentes pois o dispositivo somente reconhecia a classe de seu IP.
Continuar lendo