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.

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.

* 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.

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.

Para a versão R71 e superiores:

Para evitar o IPS para uma proteção específica:

Abra o SmartDashboard e vá na aba IPS.
Vá na seção “Protections”.
Encontre a proteção que você quer evitar.
Vá na aba “Network Exception”.
Clique em “New”.
Adicione uma nova exceção para essa proteção específica.
Instale a politica de segurança.

Para evitar o IPS para uma rede inteira:

Abra o SmartDashboard e vá na aba IPS.
Vá na aba “Network Exception”.
Clique em “New”.
dicione uma nova exceção para essa rede.
Instale a politica de segurança

Para a versão R70:

Use o mesmo procedimento da versão NGX R65. Note que para o R70 isso funciona quando uma dessas proteções do IPS estiverem habilitadas:

HTTP format sizes
HTTP methods
HTTP request
HTTP Worm Catcher
HTTP directory traversal
HTTP cross sites scripting
HTTP SQL injection
HTTP command stealth
HTTP generic header spoofing
HTTP header rejection
HTTP buffer overflow
HTTP response
HTTP error concealment
HTTP LDAP injection
HTTP directory listing
URL logging and Quick UFP (from resource)
Uma das proteções p2p
Uma das proteções para mensagens instantâneas

Nota:
Todas as alterações devem ser feitas no arquivo $FWDIR/lib/asm.def.
selecione a caixa de seleção “Apply to all HTTP traffic” e instale a politica de segurança.

Para NGX R65:

Nota: faça todas as alterações no arquivo $FWDIR/lib/asm.def no SmartCenter Server.

Procedimento:

Prepare uma lista de endereços IP para os quais você quer evitar as proteções do IPS/Web Intelligence.
Faça um backup do arquivo no SmartCenter Server.
Edite o arquivo no SmartCenter Server:
Adicione a seguinte linha no começo do arquivo (essa lista representa os endereços IP problemáticos):

IPList = {<IP1>,<IP2>,<IP3>};

Exemplo:

IPList = {1.1.1.2,1.1.2.2};

Nota: você também pode usar uma lista de endereços IP usando a seguinte sintaxe:

IPList = {<IP_inicio,IP_fim>,<IP_inicio,IP2_fim>};

Por exemplo:

IPList = {<1.1.1.1,1.1.1.5>, <2.2.2.2,2.2.3.3>};

Ache a linha a seguir:
#define ACTIVATE_WS_GLOBAL_DEFENSE (tcp, dport in http_services,ADD_INSPECTION(SPII_WEBSEC_ID)) or 1

Altere a linha da seguinte forma:
#define ACTIVATE_WS_GLOBAL_DEFENSE (src not in IPList,dst not in IPList,tcp, dport in http_services,ADD_INSPECTION(SPII_WEBSEC_ID)) or 1

Ache a linha a seguir:
#define ACTIVATE_WS_SERVER_DEFENSE ( tcp, get from web_server_rules to sr10, ADD_INSPECTION_WITH_PARAMS(SPII_WEBSEC_ID, sr10)) or ACTIVATE_WS_GLOBAL_DEFENSE

Altere a linha da seguinte forma:
#define ACTIVATE_WS_SERVER_DEFENSE ( src not in IPList,dst not in IPList,tcp, get from web_server_rules to sr10, ADD_INSPECTION_WITH_PARAMS(SPII_WEBSEC_ID, sr10)) or ACTIVATE_WS_GLOBAL_DEFENSE

Nota:
No VPN-1 Power/UTM NGX R65 essas funções foram modificadas:

#define ACTIVATE_WS_GLOBAL_DEFENSE

(
src not in IPList,dst not in IPList,tcp, dport in http_services,

((is_version_at_least(NGXENF_VER),call KFUNC_IS_NOTIFY<>) or ADD_INSPECTION(SPII_WEBSEC_ID))

) or 1

#define ACTIVATE_WS_SERVER_DEFENSE

(
src not in IPList,dst not in IPList,tcp, get  from web_server_rules to sr10,

((is_version_at_least(NGXENF_VER),call KFUNC_IS_NOTIFY<>) or ADD_INSPECTION_WITH_PARAMS(SPII_WEBSEC_ID, sr10))

) or ACTIVATE_WS_GLOBAL_DEFENSE

Tenha certeza de sempre adicionar a parte (src not in IPList,dst not in IPList) depois de #define <nome da função>.

Instale a politica de segurança para ativar as alterações.

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.

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)

Como podem haver muitos pacotes passando ao mesmo tempo pelo firewall, nós precisamos de alguma forma determinar quais pacotes queremos ver. Fazemos isso usando um filtro de inspeção (INSPECT filter) que pode ser digitado diretamente via linha de comando, ou via um arquivo INSPECT filter. Em qualquer dessas opções (-f ou -e) é necessário.

Uma vez que você executou este comando, O firewall irá compilar o script INSPECT (via linha de comando, ou via arquivo), carregá-lo no modulo de kernel, e mostrar os pacotes na janela do terminal, ou num arquivo de saída no formato snoop. O processo do fw monitor irá continuar rodando até que um sinal de interrupção seja enviado para o programa (ex.: Ctrl-C), o que causará a parada imediata do processo fw monitor.

O script INSPECT deverá retornar um “accept” para que os pacotes sejam mostrados. Qualquer outro código de retorno ocorrerá que os pacotes não serão mostrados. Se você quiser apenas olhar pacotes numa interface, não use ‘eth-s1p1@all’ (por exemplo), e sim use ‘direction=x,ifid=y’ onde x=0 para entrada, 1 para saída, e y é o número da interface mostrado pelo comando fw ctl iflist. Não use os nomes de tabelas que são utilizadas pelo Check Point Firewall.

Exemplos:

O exemplo a seguir mostrará todos os pacotes TCP entrando e saindo do Firewall. O comando mostrará até 80 bytes do cabeçalho TCP e a parte de dados (assumindo que nenhuma opção IP está sendo usada).

    ipso[admin]# fw monitor -e ‘[9:1]=6, accept;’ -l 100 -m iO -x 20

O exemplo a seguir mostrará todos os pacotes TCP entrando e saindo do Firewall na direção de entrada (Ex. antes de o sistema operacional rotear o pacote).

    ipso[admin]# fw monitor -e ‘accept;’ -m iI

O exemplo a seguir mostrará todos os pacotes na interface com ID 0 vindo, ou indo para 10.0.0.1. O valor usado de ifid corresponde

ao número dado para uma interface pelo firewall. Você pode determinar qual interface tem qual número usindo o comando:
fw ctl iflist

    ipso[admin]# fw monitor -e ‘accept ifid=0,src=10.0.0.1 or dst=10.0.0.1;’

O exemplo a seguir faz a mesma coisa que o comando acima com a exceção de olhar apenas pacotes IP Protocolo 47.

    ipso[admin]# fw monitor -e ‘accept ifid=0,src=10.0.0.1 or dst=10.0.0.1,ip_p=47;’

O exemplo a seguir mostrará todos os pacotes tcp indo para ou vindo de 10.0.0.1 com a porta 80 sendo tanto na origem quanto no destino.

    ipso[admin]# fw monitor -e ‘accept PROTO_tcp,dport=80 or sport=80,src=10.0.0.1 or dst=10.0.0.1;’

Outros exemplos comuns

ipso[admin]# fw monitor –e „accept (src=x.x.x.x or dst=x.x.x.x);“

ipso[admin]# fw monitor –e „accept (src=x.x.x.x, dst=y.y.y.y);“

ipso[admin]# fw monitor –e „accept ((src=x.x.x.x, dst=y.y.y.y) or (src=y.y.y.y, dst=x.x.x.x));“

Cuidados:

    Não modifique tabelas utilizadas em uma política, comportamento não esperado poderá ocorrer (incluindo crash do sistema). 

   Pacotes são desfragmentados quando saem do Firewall tanto em entrada e saída.

   Qualquer ação que carregue, descarregue ou instale uma política vai fazer com que o fw monitor pare.

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.

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”.
Detalhes da sintaxe:

Uso: ip route { list | flush } SELETOR

       ip route get ADDRESS [ from ENDEREÇO iif STRING ]

                            [ oif STRING ]  [ tos TOS ]

       ip route { add | del | change | append | replace | monitor } ROTA

SELETOR := [ root PREFIXO ] [ match PREFIXO ] [ exact PREFIXO ]

            [ table TABLE_ID ] [ proto RTPROTO ]

            [ type TIPO ] [ scope ESCOPO ]

ROTA := NODE_SPEC [ INFO_SPEC ]

NODE_SPEC := [ TIPO ] PREFIXO [ tos TOS ]

             [ table ID_DA_TABELA ] [ proto RTPROTO ]

             [ scope ESCOPO ] [ metric MÉTRICA ]

INFO_SPEC := NH OPÇÕES FLAGS [ nexthop NH ]...

NH := [ via ENDEREÇO ] [ dev STRING ] [ weight NÚMERO ] NHFLAGS

OPÇÕES := FLAGS [ mtu NÚMERO ] [ advmss NÚMERO ]

           [ rtt NÚMERO ] [ rttvar NÚMERO ]

           [ window NÚMERO] [ cwnd NÚMERO ] [ ssthresh REALM ]

           [ realms REALM ]

TIPO := [ unicast | local | broadcast | multicast | throw |

          unreachable | prohibit | blackhole | nat ]

ID_DA_TABELA := [ local | main | default | all | NÚMERO ]

ESCOPO := [ host | link | global | NÚMERO ]

FLAGS := [ equalize ]

NHFLAGS := [ onlink | pervasive ]

RTPROTO := [ kernel | boot | static | NÚMERO ]

Exemplo:

[Expert@R61]# ip route add 2.1.1.0/24 via 194.29.42.179

Kernel IP routing table

Destination     Gateway         Genmask         Flags Metric Ref    Use Iface

224.0.0.2       0.0.0.0         255.255.255.255 UHD   0      0        0 lo

127.0.0.1       0.0.0.0         255.255.255.255 UH    0      0        0 lo

194.29.42.128   0.0.0.0         255.255.255.128 U     0      0        0 eth0

20.20.20.0      0.0.0.0         255.255.255.0   U     0      0        0 eth1

10.10.10.0      20.20.20.114    255.255.255.0   UG    0      0        0 eth1

2.1.1.0         194.29.42.179   255.255.255.0   UG    0      0        0 eth0

192.168.121.0   0.0.0.0         255.255.255.0   U     0      0        0 eth2

127.0.0.0       -               255.0.0.0       !D    0      -        0 -

0.0.0.0         194.29.42.129   0.0.0.0         UG    0      0        0 eth0

Para salvar a configuração (note que essa operação faz a alteração ficar persistente, ou seja a rota não será perdida após um reboot), faça o seguinte:

[Expert@R61]# route --save

Expert@R61]# reboot

Are you sure? (y/n) y

Broadcast message from root (ttyp0) (Mon Oct 23 04:11:40 2006):

The system is going down for reboot NOW!

Kernel IP routing table

Destination     Gateway         Genmask         Flags Metric Ref    Use Iface

224.0.0.2       0.0.0.0         255.255.255.255 UHD   0      0        0 lo

127.0.0.1       0.0.0.0         255.255.255.255 UH    0      0        0 lo

194.29.42.128   0.0.0.0         255.255.255.128 U     0      0        0 eth0

20.20.20.0      0.0.0.0         255.255.255.0   U     0      0        0 eth1

10.10.10.0      20.20.20.114    255.255.255.0   UG    0      0        0 eth1

2.1.1.0         194.29.42.179   255.255.255.0   UG    0      0        0 eth0

192.168.121.0   0.0.0.0         255.255.255.0   U     0      0        0 eth2

127.0.0.0       -               255.0.0.0       !D    0      -        0 -

0.0.0.0         194.29.42.129   0.0.0.0         UG    0      0        0 eth0

Basedo na solução sk32170
Se aplica à SecurePlatform, SecurePlatform 2.6 executando NGX R65, R70, R71, R75

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.
CST versão 2007-09-26
Usage: cst [-small] [-nocpinfo] [-batch] [-o dir]

-small
não captura certos arquivos (como logs do firewall e arquivos
vmcore) no entanto faz o arquivo cst resultante bem menor.
-nocpinfo
não executa cpinfo, in case it ends up hanging cst collection.

-batch
não faz nenhuma pergunta (pode ser executado em plano de fundo)
-o dir
faz com que o diretório de saída seja “dir”, requerido se estiver usando -batch

O CST reporta o hash MD5 de arquivos chaves do sistema. Isso é importante se arquivos vmcore exsitem no sistema e se uma análise será realizada. A informação MD5 reportada pelo CST garante que o kernel e os módulos corretos são usados durante a analise.

O CST pega todos os arquivos vmcore do kernel do IPSO do diretório /var/crash se ele existir no sistema. Para fazer uma análise do arquivos vmcore, o suporte deve requisitar os arquivos do diretório $FWDIR/boot/modules/*.o do mesmo sistema onde os erros ocorreram. O arquivo de saída do eCST inclue os arquivos vmcore e também os arquivos *.o do sistema, eliminando assim a necessidade de pedir aqueles arquivos separadamente.

O CST no IPSO 3.6 e superior, gera relatórios com histórico de utilização de CPU, utilização de memória, e tráfego de todas as interfaces. Esses relatóris contem gráficos em forma de pizza assim como todos os dados coletados.

O CST também inclue informação de depuração sobre VRRP, RIP, OSPF, BGP, e DVMRP.

Ambos CST/eCST e CPINFO incluem um dump completo da tabela de conexões. Em sistemas que tem uma tabela de conexões muito grande, coletar esses dados pode ser uma tarefa muito custosa. Isso pode acabar fazendo o script do CST ser executado continuamente e nunca terminar. Em sismtas que tem muita carga de utilização é melhor executar o CST com uma prioridade baixa. O comando”nice +20 cst” talvez seja  necessário em caixas que estejam extramamente ocupadas, isso forçará o CST a ser  executado com a menor prioridade possivel.

Dependendo das condições do tráfego ativo ou do número de conexões, CST pode causar um maior uso da CPU e da memória no sistema enquanto está sendo executado.

Ao executar o CST você verá mensagens parecidas com essas:

meu-firewall[admin]# cst
IPSO 3.6x or earlier kernel found…
CST version 2006-12-26

=============== N O T I C E:  VOYAGER LOCKS =========================
Please make sure you are logged out of Voyager.
CST gathers certain information from clish, which may not work
when there is a configuration lock in place established by an active
Voyager session.
=============== E N D   O F   N O T I C E    =========================

Continue? [y]

y
Output Directory? [.] /var/tmp
IPSO-4.2-BUILD111 detected…
Generating IPv4 configuration summary…done
Generating IPv6 configuration summary…done
Gathering cpu utilization data…done
Gathering memory utilization data…done
Gathering interface statistics…done
Gathering standard ipsoinfo data…done
Gathering additional ipso information…
vrrp data…done
route data…done
rip data…done
ospf data…done
bgp data…done
dvmrp data…done
pim data…done
…done
Gathering system logs……done
Processsing vmcore files…none on this system…..done
Gathering firewall data… Invalid flavour ‘general’ for product ‘vpn’. Use ‘cpstat’ without any arguments to see supported products and flavours.
Invalid flavour ‘fwz’ for product ‘vpn’. Use ‘cpstat’ without any arguments to see supported products and flavours.
…done
Fetching cpinfo…
cpinfo (I:0110):        Beginning …

cpinfo (I:0116):        Latest cpinfo build: http://www.checkpoint.com/techsupport/downloadsng/utilities.html#cpinfo
cpinfo (I:0112):        Embedding files …

cpinfo (I:0120):        Output file  – cst-meu-firewall-11.04.2011-0825/cpinfo.meu-firewall.11.04.2011-0825
cpinfo (I:0111):        Done
done
Creating index…done
Creating archive file…done

Searching for system and process core files…done
Fetching routing daemon state…done
Compressing final archive…done

Output saved to /var/tmp/cst-meu-firewall-11.04.2011-0825.tar.gz

Depois que o arquivo de saída for gerado, no caso do exemplo acima /var/tmp/cst-meu-firewall-11.04.2011-0825.tar.gz, você pode usar o comando md5 para gerar um hash md5 antes de transferir o arquivo para uma localidade remota, depois de transferir o arquivo você pode usar o md5sum ou alguma ferramenta equivalente para garantir que o arquivo foi transferido corretamente.

meu-firewall[admin]# md5 cst-meu-firewall-11.04.2011-0825.tar.gz
MD5 (cst-meu-firewall-11.04.2011-0825.tar.gz) = 89a3dc1a5l60207d1b25b81a31cf8531

Você pode fazer download de um arquivo CST de exemplo no link: Arquivo CST de exemplo.

Até mais!

O host A (172.16.10.100) na subnet A quer enviar pacotes para o host D (172.16.20.200) na subnet B. Como mostrado no diagrama, o host A possui máscara de rede classe B (255.255.0.0). Isso significa que o host A acredita estar em uma rede diretamente conectada com toda rede 172.16.0.0/16. Quando o host A necessita se comunicar com qualquer device que acredita estar diretamente conectado, ele envia um ARP request (o famoso pacote “Who has IP_x.x.x.x ? Tell to x.x.x.x).

Porém, como um arp request é um pacote broadcast, e por default routers não propagam broadcast, este request nunca chegará ao host D. Porém, como o device Router conhece a subnet onde o host D está, o Router em si irá responder o arp-request enviado para o IP 172.16.20.200, como sendo o mac-address 00-00-0c-94-36-ab, e todos os pacotes enviados do host A para o host D terão o fluxo host_A->Router->host_D. Porém, tudo isso será transparente para o host A e host D.

• Host A necessita enviar um pacote para o host D;
• Host A envia um arp-request querendo saber o mac-address do host D 172.16.20.200
• Router recebe o arp-request, e o responde que o IP 172.16.20.200 possui o mac-address 00-00-0c-94-36-ab;
• Host A envia um pacote para o mac-address 00-00-0c-94-36-ab;
• Router recebe o pacote e encaminha ao host D;
• Host D recebe o pacote com o campo origem IP 172.16.10.100, mac-address 00-00-0c-94-36-cd;
• Como o host D conhece o conceito de subnet e sabe que o host A está em outra subnet, este envia a resposta para o IP 172.16.10.100 ao seu default-gateway 172.16.20.99;
• Router encaminha o pacote ao host A como origem 172.16.20.200, mac-address 00-00-0c-94-36-ab.

Bem, tudo isso é muito confuso a parece não ser muito necessário nos dias de hoje. Porém há ainda muitas redes onde utilizam sistemas legados ou falsos dispositivos que são vendidos como “TCP/IP enabled” como catracas eletrônicas, relógios de ponto, PLCs entre outros, e nesses casos a utilização de proxy arp se faz necessário. Mas a utlização de tal método possui mais desvantagens do que vantagens. Entre as desvantagens podemos citar o aumento de tráfego ARP em determinado segmento de rede, podendo até mesmo causar issues de high cpu nos routers. Outra desvantagem é que os computadores que não tem configuração de subnet necessitarão de grandes tabelas ARP. Um outro ponto é a segurança, uma vez que em um cenário desses fica fácil a utilização da técnica em spoofing.

No exemplo de debug abaixo, foi utilizado a topologia acima com os mesmos Ips. O primeiro comando ping à partir do HOST_A foi dado com o proxy-arp desabilitado no device ROUTER. Notem que o ROUTER recebe os ARP Request, porém não envia nenhuma resposta. No segundo ping, o proxy-arp está habilitado na interface diretamente conectada ao HOST_A. o ROUTER envia o arp reply logo em seguida que recebe o arp request do HOST_A.

[ROUTER]
ROUTER(config)#int f1/0
ROUTER(config-if)#no ip proxy-arp
*Feb 13 22:36:04.719: IP ARP: rcvd req src 172.16.10.100 c801.1f95.0010, dst 172.16.20.200 FastEthernet1/0
*Feb 13 22:36:24.227: IP ARP: rcvd req src 172.16.10.100 c801.1f95.0010, dst 172.16.20.200 FastEthernet1/0
*Feb 13 22:36:26.287: IP ARP: rcvd req src 172.16.10.100 c801.1f95.0010, dst 172.16.20.200 FastEthernet1/0
*Feb 13 22:36:28.287: IP ARP: rcvd req src 172.16.10.100 c801.1f95.0010, dst 172.16.20.200 FastEthernet1/0
*Feb 13 22:36:30.291: IP ARP: rcvd req src 172.16.10.100 c801.1f95.0010, dst 172.16.20.200 FastEthernet1/0
*Feb 13 22:36:32.295: IP ARP: rcvd req src 172.16.10.100 c801.1f95.0010, dst 172.16.20.200 FastEthernet1/0

ROUTER(config-if)#ip proxy-arp
*Feb 13 22:36:57.791: IP ARP: rcvd req src 172.16.10.100 c801.1f95.0010, dst 172.16.20.200 FastEthernet1/0
*Feb 13 22:36:57.795: IP ARP: sent rep src 172.16.20.200 ca02.1f95.001c, dst 172.16.10.100 c801.1f95.0010 FastEthernet1/0

[HOST_A]
HOST_A#ping 172.16.20.200

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 172.16.20.200, timeout is 2 seconds:

*Mar 1 00:26:02.855: IP ARP: creating incomplete entry for IP address: 172.16.20.200 interface FastEthernet1/0
*Mar 1 00:26:02.859: IP ARP: sent req src 172.16.10.100 c801.1f95.0010,
dst 172.16.20.200 0000.0000.0000 FastEthernet1/0.
*Mar 1 00:26:04.855: IP ARP: sent req src 172.16.10.100 c801.1f95.0010,
dst 172.16.20.200 0000.0000.0000 FastEthernet1/0.
*Mar 1 00:26:06.855: IP ARP: sent req src 172.16.10.100 c801.1f95.0010,
dst 172.16.20.200 0000.0000.0000 FastEthernet1/0.
*Mar 1 00:26:08.855: IP ARP: sent req src 172.16.10.100 c801.1f95.0010,
dst 172.16.20.200 0000.0000.0000 FastEthernet1/0.
*Mar 1 00:26:10.855: IP ARP: sent req src 172.16.10.100 c801.1f95.0010,
dst 172.16.20.200 0000.0000.0000 FastEthernet1/0.
Success rate is 0 percent (0/5)

HOST_A#ping 172.16.20.200

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 172.16.20.200, timeout is 2 seconds:

*Mar 1 00:26:36.419: IP ARP: sent req src 172.16.10.100 c801.1f95.0010,
dst 172.16.20.200 0000.0000.0000 FastEthernet1/0
*Mar 1 00:26:36.475: IP ARP: rcvd rep src 172.16.20.200 ca02.1f95.001c, dst 172.16.10.100 FastEthernet1/0.!!!!
Success rate is 80 percent (4/5), round-trip min/avg/max = 56/163/200 ms

Autor: Rodrigo Varela Simões