cancelar
Mostrar resultados para 
Pesquisar em vez de 
Queria dizer: 
cancel
Comunicados
Bem-vindo à Comunidade de Suporte da Cisco, gostaríamos de ter seus comentários.
ATE_Umbrella_Andre

Segurança Blogues

Rótulos
55 visualizações
0 Comentários

Enfim temos VPN Remote Access no Cisco FTD.

A funcionalidade foi lançada na versão 6.2.1, apenas para os appliances Firepower 2100. E agora, a partir da versão 6.2.2 (lançada em setembro), a funcionalidade está disponível para todos os appliances.

FTD 6.2.2

Ainda não temos todas as opções que tínhamos anteriormente no Cisco ASA (que convenhamos era uma solução bastante completa), mas as principais funcionalidades estão disponíveis.

  • Gerenciamento: Feito através do FMC ou FDM, possui um wizard para configuração, onde configuramos profiles, políticas, pool de endereços, adicionamos a imagem do Anyconnect, e selecionamos a interface onde a VPN será habilitada.
  • Acesso Seguro: Fornecido pelo cliente Cisco AnyConnect (computadores, dispositivos Android e IOS) usando protocolos de encapsulamento e codificação SSL ou IPsec.
  • AAA: Suporte à autenticação (LDA / AD / RADIUS, usando usuário e senha e/ou certificado), autorização (atributos RADIUS – DACL, política de grupos, atribuição de IP, etc), contabilidade (accounting) RADIUS.
  • Conectividade: Os perfis de conexão e as políticas de grupo permite definirmos o servidor DNS, o horário permitido para acesso, ACLs de firewall para o cliente.
  • Solução de Problemas: Tela para troubleshooting, com logs úteis para solução de problemas na criação ou uso da VPN RA.
  • Disponibilidade: O firewall pode estar em HA, ter múltiplas interfaces (dois ISPs) e vários servidores AAA.
  • Licenciamento: Smart Licensing, baseado na versão AnyConnect 4.x, para licenças Apex, Plus e VPN-Only.

 

 

Mais informações sobre VPN RA no FTD e outras novas funcionalidades disponíveis na versão 6.2.2 no release notes.

Até a próxima.

25 visualizações
0 Comentários

CCIE Segurança escrito e laboratório exames foram revistos para a versão 5.0 utilizando o novo modular e unificado exame tópicos formato, incluindo a avaliação das tecnologias em evolução. Os exames escritos e de laboratório v5.0 estarão disponíveis para teste em 31 de janeiro de 2017. Ver CCIE Security Unified Exam Topics v5.0 (Recomendado para o calendário de candidatos para fazer o exame em 31 de janeiro de 2017 e além) O último dia para testar usando o exame escrito 350-018 usando seus tópicos correspondentes do exame v4.0 é 24 de julho de 2016. A partir de 25 de julho de 2016, exame escrito 350-018 usando os tópicos do exame v4.1 que inclui o domínio "Evolving Technologies" estará disponível para testes no Pearson Vue. O último dia para testar usando o exame de laboratório v4.0 é 30 de janeiro de 2017.

Revisao de Tópicos CCIE Security

cciesec_v4_v5_changes cciesec_v4_v5_wr

Formato do Lab

A infra-estrutura de entrega baseada na Web que suporta o exame de laboratório v5.0 é muito semelhante à v4.0. O formato do exame de laboratório em si, no entanto, mudou significativamente. O exame de laboratório v5.0 agora compreende três módulos:

  1. Troubleshooting Module
  2. Diagnostic Module
  3. Configuration Module

cciesec_v4_v5_diag cciesec_v4_v5_lab

CCIE Security v5.0 Written and Lab Exam Content Updates

CCIE Security

43 visualizações
0 Comentários

Os ficheiros XML e de perfil são armazenados localmente na máquina dos utilizadores. A localização varia de acordo com o sistema operativo.

Windows XP

%ALLUSERSPROFILE%\Application Data\Cisco\Cisco AnyConnect Secure Mobility Client\Profile

Windows Vista

%ProgramData%\Cisco\Cisco AnyConnect Secure Mobility Client\Profile

Windows 7

%ProgramData%\Cisco\Cisco AnyConnect Secure Mobility Client\Profile

Mac OS X

/opt/cisco/anyconnect/profile

Linux

/opt/cisco/anyconnect/profile

61 visualizações
0 Comentários

Esta mensagem de erro é porque o Cisco ASA não tem a imagem AnyConnect para o seu perfil WebVPN. Essas imagens podem ser cisco.com .Este exemplo é para ASDM 7.6, mas se você executar versão 6.x usando ASDM Configuration > Remote Access VPN > Network (Client) Access > AnyConnect Customization/Localization > Binary

anyconnect_package_error anyconnect_package_error4 anyconnect_package_error2 anyconnect_package_error3

602 visualizações
0 Comentários

O NAT é definido no RFC 1631

Name Location of Host Represented by Address IP Address Space in Which Address Exists
Inside Local address Inside the enterprise network Part of the enterprise IP address space;typically a private IP address
Inside Global address Inside the enterprise network Part of the public IP address space
Outside Local address In the public Internet; or, outside the enterprise network Part of the enterprise IP address space; typically a private IP address
Outside Global address In the public Internet; or, outside the enterprise network Part of the public IP address space

Ligações:

R1——-s2/1-(outside)R2-(Inside)f0/1———-f0/0-R3

Exemplo 1:

Usando Static NATs

R2(config)#
ip route 0.0.0.0 0.0.0.0 192.168.2.1

interface FastEthernet0/1
ip address 192.168.20.2 255.255.255.0
 ip nat inside

interface Serial2/1
ip address 192.168.2.2 255.255.255.0
 ip nat outside

ip nat inside source static 1.1.1.1 2.2.2.1

R3(config)#
ip route 0.0.0.0 0.0.0.0 192.168.20.2
interface FastEthernet0/0
ip address 192.168.20.1 255.255.255.0

interface Loopback11
ip address 1.1.1.1 255.255.255.255
interface Loopback14
ip address 1.1.1.4 255.255.255.255
interface Loopback15
ip address 1.1.1.5 255.255.255.255
interface Loopback16
ip address 1.1.1.6 255.255.255.255
interface Loopback17
ip address 1.1.1.7 255.255.255.255
interface Loopback18
ip address 1.1.1.8 255.255.255.255
interface Loopback19
ip address 1.1.1.9 255.255.255.255
interface Loopback20
ip address 1.1.1.10 255.255.255.255

R3#ping 192.168.10.1 so loop11

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 192.168.10.1, timeout is 2 seconds:
Packet sent with a source address of 1.1.1.1
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 36/40/48 ms

R2#sh ip nat trans
Pro Inside global      Inside local       Outside local      Outside global
icmp 2.2.2.1:5         1.1.1.1:5          192.168.10.1:5     192.168.10.1:5

Exemplo 2:

Usando Dynamic NAT

R2(config)#

!Identificar as origens que usam o NAT
access-list 1 permit 1.1.1.4 0.0.0.3

!Criar a pool de IPs
ip nat pool Pool1 2.2.2.4 2.2.2.7 prefix-length 30

ip nat inside source list 1 pool Pool1

R3#ping 192.168.10.1 so loop11

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 192.168.10.1, timeout is 2 seconds:
Packet sent with a source address of 1.1.1.1
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 36/40/48 ms

R3#telnet 192.168.10.1 /source-interface loop15
Trying 192.168.10.1 … Open

R2#sh ip nat statistics
Total active translations: 5 (1 static, 4 dynamic; 2 extended)
Outside interfaces:
Serial2/1
Inside interfaces:
FastEthernet0/1
Hits: 108  Misses: 0
CEF Translated packets: 104, CEF Punted packets: 2
Expired translations: 6
Dynamic mappings:
— Inside Source
[Id: 1] access-list 1 pool Pool1 refcount 4
 pool Pool1: netmask 255.255.255.252
        start 2.2.2.4 end 2.2.2.7
        type generic, total addresses 4, allocated 2 (50%), misses 0
Appl doors: 0
Normal doors: 0
Queued Packets: 0

R2#sh ip nat translations
Pro Inside global      Inside local       Outside local      Outside global
tcp 2.2.2.6:52716      1.1.1.5:52716      192.168.10.1:23    192.168.10.1:23
— 2.2.2.6            1.1.1.5            —                —
icmp 2.2.2.5:2         1.1.1.6:2          192.168.10.1:2     192.168.10.1:2
— 2.2.2.5            1.1.1.6            —                —
— 2.2.2.1            1.1.1.1            —                —

Exemplo 3:

Usando NAT overload

!Overload atraves de uma Pool

access-list 2 permit 1.1.1.8
ip nat pool Pool_GLOBAL 2.2.2.8 2.2.2.11 netmask 255.255.255.252
ip nat inside source list 2 pool Pool_GLOBAL overload

R3#telnet 192.168.10.1 /source-interface loop18

R2#sh ip nat translations
Pro Inside global      Inside local       Outside local      Outside global
— 2.2.2.1            1.1.1.1            —                —
tcp 2.2.2.10:39915     1.1.1.8:39915      192.168.10.1:23    192.168.10.1:23
tcp 192.168.2.2:19724  1.1.1.9:19724      192.168.10.1:23    192.168.10.1:23
tcp 192.168.2.2:51357  1.1.1.10:51357     192.168.10.1:23    192.168.10.1:23

Usando NAT overload da interface Outside

 

!Identificar as origens que usam o NAT
access-list 3 permit 1.1.1.9
access-list 3 permit 1.1.1.10

ip nat inside source list 3 interface Serial 2/1 overload

R3#telnet 192.168.10.1 /source-interface loop19
R3#telnet 192.168.10.1 /source-interface loop20

R2#sh ip nat translations
Pro Inside global      Inside local       Outside local      Outside global
— 2.2.2.1            1.1.1.1            —                —
tcp 2.2.2.10:39915     1.1.1.8:39915      192.168.10.1:23    192.168.10.1:23
tcp 192.168.2.2:19724  1.1.1.9:19724      192.168.10.1:23    192.168.10.1:23
tcp 192.168.2.2:51357  1.1.1.10:51357     192.168.10.1:23    192.168.10.1:23

113 visualizações
1 Comentário

As policies do classic IOS inspection aplicam-se a todo o tréfego na interface, não é possível aplicar policies distintas a diferentes grupos de users. O Zone-based firewall (ZFW), disponivel apartir da IOS Release 12.4(6)T já o permite.

O tráfego pode circular livremente entre interface da mesma zone, mas é bloqueado by default entre zones.

As Zone Policies são configuradas usando o Class-Based Policy Language (CPL), que é muito similar á CLI do Modular QoS Command Line Interface (MQC) que usa class/policy maps.

Foi introduzida uma nova class e policy map type (inspect  type) para usar nas zone-based firewalls.

O ZBF permite o inspection e controlos de diversos protocolos tais como:

  • HTTP e HTTPS
  • SMTP, Extended SMTP (ESMTP), POP3 e IMAP
  • Aplicações Peer-to-peer, com a habilidade para usar heuristics to track port hopping
  • Instant messaging applications (AOL, Yahoo!, and MSM)
  • Remote Procedure Calls (RPC)

Passos para configurar o ZFW:

  1. Decidir as zones necessárias, e criá-las no router
  2. Decidir que tráfego deve circular entre as zones, e criar as zone-pairs no router
  3. Criar class maps para identificar o tráfego a ser inspect pelo firewall entre zones
  4. Assignar policies ao tráfego criando policy maps e associando class maps
  5. Assignar policy maps ás zone-pair apropriados
  6. Assignar as interfaces ás zones. Uma interface apenas pode pertencer a uma security zone

O router cria automaticamente uma zona para o seu próprio tráfego, de nome self zone. Todo o tráfego de/para esta zona é permitido, pode no entanto ser alterado.

As Policy maps podem tomar as seguintes acções para cada class:

  • Drop — Drop the packet
  • Inspect — Use Context-based Access Control Engine
  • Pass — Pass the packet
  • Police — Police the traffic
  • Service-policy — Use Deep Packet Inspection Engine
  • Urlfilter — Use URL Filtering Engine

Podem ser usados parameters maps para gerar alertas, audit trails, e controlar os parâmetros de sessão p.ex. o nº sessões half-open, Idle das sessões,etc.

Exemplo:

Ligações:

R1——s2/1-R2-f0/1———-f0/0-R3

Acessos:

Garantir o telnet e http apartir do R3 para qualquer destino, devem ser ainda inspecionados os requests GET no http e gerado log.Qualquer acesso apartir do INSIDE excluindo os mencionados anteriormente, devem ter o idle-timeout para 100 segundos. Será ainda possível ter respostas ao PING apartir do OUTSIDE

zone security INSIDE
zone security OUTSIDE

Interface S2/1
zone-member security OUTSIDE

Interface F0/1
zone-member security INSIDE

zone-pair security INSIDE-OUTSIDE source INSIDE destination OUTSIDE
zone-pair security OUTSIDE-INSIDE source OUTSIDE destination INSIDE

ip access-list extended TELNET
permit tcp any any eq telnet

ip access-list extended other_Traffic
permit ip any any

parameter-map type inspect TIMEOUT
udp idle-time 100
tcp idle-time 100

class-map type inspect match-all other_Traffic
match access-group name other_Traffic

class-map type inspect match-all TELNET
match access-group name INSIDE-OUTSIDE
match protocol telnet

! Os requests Get no protocolo HTTP serao inspect
class-map type inspect http method_HTTP
 match  request method get

class-map type inspect match-all _HTTP
match protocol http
!
!Esta policy para DPI tem que ser criada separadamente
policy-map type inspect http DPI_HTTP
class type inspect http method_HTTP
log

policy-map type inspect zbf_INSIDE-OUTSIDE
class type inspect TELNET
inspect
 class type inspect _HTTP
  inspect
 service-policy http DPI_HTTP
class type inspect other_Traffic
inspect TIMEOUT
!
!Definir os acessos apartir do OUTSIDE
zone-pair security INSIDE-OUTSIDE source INSIDE destination OUTSIDE

class-map type inspect match-all ICMP
match protocol icmp

policy-map type inspect zbf_OUTSIDE-INSIDE
class type inspect ICMP
inspect

zone-pair security OUTSIDE-INSIDE source OUTSIDE destination INSIDE
 service-policy type inspect zbf_OUTSIDE-INSIDE

R2#sh zone security
zone self
Description: System defined zone

zone INSIDE
Member Interfaces:
FastEthernet0/1

zone OUTSIDE
Member Interfaces:
Multilink1

R2#sh parameter-map type inspect

parameter-map type inspect TIMEOUT
audit-trail off
alert on
max-incomplete low  unlimited
max-incomplete high unlimited
one-minute low  unlimited
one-minute high unlimited
udp idle-time 100
icmp idle-time 10
dns-timeout 5
tcp idle-time 100
tcp finwait-time 5
tcp synwait-time 30
tcp max-incomplete host unlimited block-time 0
sessions maximum 2147483647

R2#sh policy-map type inspect zone-pair
Zone-pair: INSIDE-OUTSIDE

Service-policy inspect : zbf_INSIDE-OUTSIDE

Class-map: TELNET (match-all)
Match: access-group name INSIDE-OUTSIDE
Match: protocol telnet
Inspect
Packet inspection statistics [process switch:fast switch]
tcp packets: [0:43]

Session creations since subsystem startup or last reset 2
Current session counts (estab/half-open/terminating) [1:0:0]
Maxever session counts (estab/half-open/terminating) [1:1:1]
Last session created 00:00:02
Last statistic reset never
Last session creation rate 1
Maxever session creation rate 1
Last half-open session total 0

Class-map: _HTTP (match-all)
Match: protocol http
Inspect
Packet inspection statistics [process switch:fast switch]
tcp packets: [1:32]
http packets: [0:6]

Session creations since subsystem startup or last reset 2
Current session counts (estab/half-open/terminating) [0:0:0]
Maxever session counts (estab/half-open/terminating) [1:1:1]
Last session created 00:41:05
Last statistic reset never
Last session creation rate 0
Maxever session creation rate 1
Last half-open session total 0
Deep packet inspection
        Policy: http DPI_HTTP
        3 packets, 72 bytes

Class-map: other_Traffic (match-all)
Match: access-group name other_Traffic
Inspect
Session creations since subsystem startup or last reset 0
Current session counts (estab/half-open/terminating) [0:0:0]
Maxever session counts (estab/half-open/terminating) [0:0:0]
Last session created never
Last statistic reset never
Last session creation rate 0
Maxever session creation rate 0
Last half-open session total 0

Class-map: class-default (match-any)
Match: any
Drop (default action)
30 packets, 2400 bytes
Zone-pair: OUTSIDE-INSIDE

Service-policy inspect : zbf_OUTSIDE-INSIDE

Class-map: ICMP (match-all)
Match: protocol icmp
Inspect
Packet inspection statistics [process switch:fast switch]
icmp packets: [0:1054]

Session creations since subsystem startup or last reset 2
Current session counts (estab/half-open/terminating) [1:0:0]
Maxever session counts (estab/half-open/terminating) [1:1:0]
Last session created 00:00:23
Last statistic reset never
Last session creation rate 1
Maxever session creation rate 1
Last half-open session total 0

Class-map: class-default (match-any)
Match: any
Drop (default action)
0 packets, 0 bytes

!Ping R3
R1#ping 192.168.20.1 re 2
Success rate is 100 percent (2/2), round-trip min/avg/max = 44/52/60 ms

!!Telnet R1

R3#telnet 192.168.10.1
Trying 192.168.10.1 … Open

User Access Verification

Password:
R2#sh policy-map type inspect zone-pair sessions
Zone-pair: INSIDE-OUTSIDE

Service-policy inspect : zbf_INSIDE-OUTSIDE

Class-map: TELNET (match-all)
Match: access-group name INSIDE-OUTSIDE
Match: protocol telnet
Inspect
   Established Sessions
         Session 670375D0 (192.168.20.1:21612)=>(192.168.10.1:23) telnet SIS_OPEN
Created 00:00:08, Last heard 00:00:07
Bytes sent (initiator:responder) [24:113]

Class-map: _HTTP (match-all)
Match: protocol http
Inspect
Deep packet inspection
Policy: http DPI_HTTP
3 packets, 72 bytes

Class-map: other_Traffic (match-all)
Match: access-group name other_Traffic
Inspect

Class-map: class-default (match-any)
Match: any
Drop (default action)
30 packets, 2400 bytes
Zone-pair: OUTSIDE-INSIDE

Service-policy inspect : zbf_OUTSIDE-INSIDE

Class-map: ICMP (match-all)
Match: protocol icmp
Inspect
Established Sessions
         Session 67037898 (192.168.2.1:8)=>(192.168.20.1:0) icmp SIS_OPEN
Created 00:00:26, Last heard 00:00:00
ECHO request
Bytes sent (initiator:responder) [36360:36288]

Class-map: class-default (match-any)
Match: any
Drop (default action)
0 packets, 0 bytes

232 visualizações
0 Comentários

Políticas de segurança no gerenciamento de senhas

 

As continuas ameaças do mundo atual exigem às empresas de segurança manter e melhorar a suas políticas de gestão em relação ao uso de senhas.

É senhas são obtidas por pessoas de fora da empresa, e assim, elas tem acesso aos recursos internos como documentos classificados, computadores, servidores e bancos de dados, que normalmente não teriam.

A maioria das vulnerabilidades e ameaças nas empresas vem do pessoal interno,  é por isso que devemos informar e treinar aos usuários sobre a importância de ter senhas com maior nível de segurança.

Os sistemas devem exigir que a senha do usuário cumpra com determinados requisitos para garantir a segurança, tais como é o uso de caracteres especiais, letras em maiúsculas, minúsculas e uso de números não repetidos nem consecutivos.

Um outro mecanismos recomendado é colocar uma "frase" que seja fácil de lembrar para o usuário.

Exemplo:
Hoje amanheceu um pouco nublado.

Poderia ser alterado usando as duas primeiras letras de cada palavra e trocá-las por números.

H04MuNP0Nu
  ou, alternativamente,
Ho14M4n3c10UN

 As senhas não podem ser reutilizáveis, ou seja, deve-se ter um banco de dados com senhas previamente configuradas pelo usuário.

Um elemento que fortalece a segurança é configurar um limite de tentativas  falhadas de acesso para os equipamentos, bloqueando a conta, e gerando  uma mensagem informando ao administrador do sistema sobre o evento.

Recomendamos  mudar regularmente as senhas para aumentar a segurança (em algumas organizações, pode ser feito cada 30 ou 90 dias).

Normalmente dentro de uma empresa existem diversas aplicações que são acedidas utilizando senhas diferentes, isto, apesar de que possa parecer mais seguro, existe uma possibilidade de os usuários não poder aprender a senha para cada um dos sistemas que trabalham dia a  dia. Portanto, você pode implementar a tecnologia de sincronização e de "Single Sign-on", para usar uma senha só para aceder todos os recursos internos.
Esta solução poder ser confortável e conveniente para os usuários finais, mas também pode trazer  novas vulnerabilidades, porque se a senha do usuário é obtida, essa pessoa pode ter acesso aos recursos da rede.

Os ataques comuns relacionados a senhas são:

Força bruta: Como o nome indica, o software irá procurar letra por letra para descobrir a senha.

Ataque de dicionário: Este ataque usa todas as palavras disponíveis no dicionário.

Olhando por cima do ombro. Você deve ter muito cuidado quando uma senha é colocada em um lugar público, pois poderia estar alguém atrás de nós, olhando nossos movimentos.

A engenharia social. Este método aproveita a disposição das pessoas para ajudar. Através do engano, uma pessoa pode fingir ser outra  dentro da empresa e convencer a vítima para obter informações confidenciais ou dados pessoais.

Pesquisar no lixo. As vezes, as informações que jogamos ao lixo podem ser úteis para outros. Você deve destruir completamente documentos sensíveis para a empresa.
Você também precisa reforçar uma política de "mesa limpa" e continuamente lembrar aos usuários para não escrever senhas em papel ou em um arquivo em seu computador.

Uma boa política de uso de senhas deve ser apoiada pelas políticas de segurança de cada empresa. A manutenção de senhas fortes e ter pessoal treinado e consciente de seu uso vai impedir que a informação seja filtrada e usada para fins negativos.

2211 visualizações
0 Comentários

Introdução

Esse documento provê exemplos de configuração de como abrir ou bloquear portas de vários tipos de tráfego, tais como HTTP ou FTP, nos dispositivos ASA e PIX nas versões mencionadas.

Nota: Os termos “abrindo a porta” e “permitindo a porta” tem o mesmo sentido. Similarmente, “bloqueando a porta” e “restringindo a porta” também tem o mesmo significado.

Pré-requisitos

Requisitos

Esse documento assume que o PIX/ASA foi previamente configurado e está funcionando apropriadamente.

Componentes utilizados

As informações deste documento são baseadas nas versões de software e hardware listadas abaixo:

  • Cisco      5500 Series Adaptive Security Appliance (ASA) que roda a versão 8.2(1)
  • Cisco      Adaptive Security Device Manager (ASDM) versão 6.3(5)

As informações contidas neste documento foram criadas tendo como base equipamentos em um ambiente laboratório. Todos os dispositivos utilizados neste documento possuíam uma configuração “padrão” (configuração default). Se seu ambiente de rede está operacional, tenha certeza que você entende o potencial impacto que qualquer comando pode ocasionar.

Configurando

Cada interface deve ter um nível de segurança que varia de 0 (o menor nível) até 100 (o maior nível). Por exemplo, você pode atribuir a sua rede mais segura, tal como sua rede inside (sua rede interna / rede na qual você tem controle do que passa e na qual você pode manter um nível de segurança mais apurado), com o nível 100. Enquanto que redes outside (ou redes externas / redes não seguras em que você não tem controle do trafego que passa por ela, tal como a internet) que estão conectadas a internet, devem ser definidas como nível 0. Outras redes tais como DMZs, podem ser posicionadas entre elas. Você pode atribuir a múltiplas interfaces o mesmo nível de segurança.

Por padrão, todas as portas na interface outside (nível de segurança 0) são bloqueadas, e todas as portas na interface inside (nível de segurança 100) são abertas no equipamento. Com isso, todo tráfego outbound (tráfego que sai de uma interface com nível de segurança alto, tal como a rede inside, para uma rede com o nível de segurança menor, tal como a rede outside) pode passar pelo equipamento sem a necessidade de configurações adicionais. No entanto, tráfegos inbounds (O contrário do trafego outbound, da Outside para Inside) podem ser permitidos através de access-lists e comandos estáticos no equipamento.

Nota: Geralmente todas as portas são bloqueadas da zona de nível de segurança mais baixo para a zona de nível de segurança mais alto, e todas as portas da zona de nível de segurança mais alto são abertas para comunicação com a zona de nível de segurança mais baixa, de modo a prover o stateful inspection habilitado em ambos os sentidos (inbound e outbound).

Diagrama de rede

Esse documento utiliza essa configuração de rede:

Configuração para bloqueio de portas

O ASA/PIX permite qualquer trafego outbound (saindo da rede interna para a externa) a menos que ele esteja explicitamente bloqueado por uma ACL estendida.

Uma access-list é formada uma ou mais ACE (Access Control Entries). Dependendo do tipo de access-list, você pode especificar o endereço IP de origem e o endereço IP de destino, protocolo, portas (para TCP ou UDP), tipo de ICMP (para ICMP) ou EtherType.

Nota: Para protocolos não orientados a conexão, tais como o ICMP, o ASA/PIX estabelece sessões unidirecionais, então você precisa definir access lists para permitir o tráfego ICMP em ambas as direções (aplicando a access list nas interfaces de origem e destino), ou você precisa habilitar a funcionalidade de ICMP inspection. Tal funcionalidade trata sessões ICMP como conexões bidirecionais.

Realize os seguintes passos para bloquear as portas, que geralmente se aplica a um trafego originado na interface inside (maior nível de segurança) para a DMZ (nível de segurança menor) ou da DMZ para a outside:

  • •1.     Crie uma Access-list de forma que filtre o trafego especifico da porta que você deseja bloquear.

access-list <nome> extended deny <protocolo> <rede-origem/IP de origem> <Máscara de rede de origem> <rede de destino/IP de destino> <Mascara de rede do destino> eq <Número da porta>

access-list <nome> extended permit ip any any

  • •2.     Então associe a access-list através do comando access-group para ativa-la:

access-group <access list name> in interface <interface name>

Exemplos:

  • •1.     Bloquear o tráfego da porta HTTP: Para bloquear a rede interna (inside) 10.1.1.0 de acessar o servidor web (HTTP) que possui o IP 172.16.1. 1 que está alocado na rede DMZ, crie uma ACL conforme abaixo:

ciscoasa(config)#access-list 100 extended deny tcp 10.1.1.0 255.255.255.0 host 172.16.1.1  eq 80

ciscoasa(config)#access-list 100 extended permit ip any any

ciscoasa(config)#access-group 100 in interface inside

Nota: Use no seguido dos comandos da access-list para remover o bloqueio da porta.

  • •2.      Bloqueando o tráfego da porta FTP: Para bloquear a rede interna (inside) 10.1.1.0 de acessar o servidor FTP (File Server) que possui o IP 172.16.1. 2 que está alocado na rede DMZ, crie uma ACL conforme abaixo:

ciscoasa(config)#access-list 100 extended deny tcp 10.1.1.0 255.255.255.0 host 172.16.1.2 eq 21

ciscoasa(config)#access-list 100 extended permit ip any any

ciscoasa(config)#access-group 100 in interface inside

Configuração para abrir portas

O Appliance de segurança não permite qualquer tipo de trafego a menos que seja explicitamente permitido através de access-list extendida.

Se você que permitir que um host externo acesse um host interno, você deve configurar e aplicar uma access-list a interface outside. Você deve especificar o endereço traduzido do host interno na access-list porque o endereço traduzido é o endereço que pode ser utilizado pela rede outside. Complete estes passos para abrir portas da zona de nível de segurança mais baixo para a zona de nível de segurança mais alto. Por exemplo, permitir o trafego da rede outside para a rede inside ou da DMZ para a rede inside.

  • •1.     O Nat estático cria uma tradução fixa de um endereço real para um endereço “mapeado”. Esse endereço mapeado é um endereço público que pode ser usado para acessar o servidor de aplicação na DMZ sem ter a necessidade de saber o verdadeiro endereço do host.

static (ifc_real,ifc_mapeado) mapped_ip {ip_real [mascara de rede] |  access-list nome_da_access_list| interface}

Consulte a sessão Static NAT do Command reference for PIX/ASA para aprender mais.

  • •2.      Crie uma ACL permitindo o trafego da porta especifica.
  • •3.     Associe a access-list com o comando access-group para ativa-la.

access-list <nome> extended permit <protocolo> <rede de origem/IP de origem> <Mascara de rede origem> <rede de destino/IP de destino> <Mascara da rede de destino> eq <Número da porta>

access-group <nome da access-list> in interface <nome da interface>

Exemplos:

  • •1.     Abrindo a porta de trafego SMTP: Abra a porta tcp 25 de forma a permitir que hosts de redes externas (tal como a Internet) possam acessar o servidor de e-mail localizado na rede DMZ.

O comando Static está mapeando um endereço externo 192.168.5.3 para um endereço real utilizado na DMZ 172.16.1.3.

ciscoasa(config)#static (DMZ,Outside) 192.168.5.3 172.16.1.3
 netmask 255.255.255.255
ciscoasa(config)#access-list 100 extended permit tcp 
 any host 192.168.5.3 eq 25
ciscoasa(config)#access-group 100 in interface outside

  • •2.     Abrindo a porta de trafego HTTPS: Abra a porta tcp 443 de forma a permitir que hosts de redes externas (tal como Internet) possam acessar o servidor web (de forma segura) localizado na rede DMZ.
  • •3.     Abrindo a porta de trafego DNS: Abra a porta UDP 53 de forma a permitir que hosts de redes externas (tal como Internet) possam acessar o servidor DNS localizado na rede DMZ.

ciscoasa(config)#static (DMZ,Outside) 192.168.5.5 172.16.1.5  netmask 255.255.255.255
ciscoasa(config)#access-list 100 extended permit tcp any host 192.168.5.5 eq 443
ciscoasa(config)#access-group 100 in interface outside
 

ciscoasa(config)#static (DMZ,Outside) 192.168.5.4 172.16.1.4 netmask 255.255.255.255
ciscoasa(config)#access-list 100 extended permit udp any host 192.168.5.4  eq 53
ciscoasa(config)#access-group 100 in interface outside

Verificação

Você pode verificar o funcionamento através de certos comandos show, conforme abaixo:

  • show xlate - exibe informações sobre traduções em funcionamento
  • show access-list - exibe uma contagem de batimento (mais conhecido como hit counts em inglês) para as entradas de uma access-lists.
  • show logging - exibe as mensagens de log do buffer do equipamento.

O Output Interpreter (Output Interpreter Tool), apenas disponível para clientes cadastrados, suporta certos comandos show. Use o mesmo para obter uma analise da saída do comando show de seu equipamento.

Troubleshoot

Não existe neste momento nenhuma informação de troubleshooting especifico para esta configuração.

Fonte: http://www.cisco.com/en/US/products/ps6120/products_configuration_example09186a0080862017.shtml

2460 visualizações
1 Comentário

Não importa se o seu projeto é de LAN,WAN, Data Center ou Comunicações Unificadas... Você sempre precisará se preocupar com os aspectos de Segurança ! E isso começa por entender as demandas negociais da sua empresa, mapear os riscos associados aos protocolos de comunicação envolvidos e conceber uma política de Segurança pertinente. A partir daí, é sempre interessante olhar para a sua rede com uma perspectiva de arquitetura, em vez de simplesmente pensar em produtos pontuais.

Numa tentativa de facilitar o acesso a tópicos importantes nesse domínio de conhecimento, decidi criar uma série de artigos, os primeiros dos quais são elencados abaixo:

Considerações sobre desempenho de Firewalls

Quando de minhas reuniões com clientes, sou freqüentemente questionado a respeito dos parâmetros mais adequados para medir o desempenho de Firewalls. Muitas das análises que vejo, se limitam a olhar o valor nominal de “throughput” (Gbps) e simplesmente ignoram aspectos vitais para o bom funcionamento de um Stateful Firewall . O presente texto é uma tentativa de revisitar tais parâmetros...

Continue reading →

Múltiplas camadas de defesa: A complementaridade do Firewall e do IPS

Não há muita discussão no que diz respeito à possibilidade de um Sistema de Prevenção de Intrusão (IPS) complementar o trabalho realizado por um firewall stateful. No entanto, é bem comum que se presenciem discussões de cunho quase filosófico sobre o posicionamento relativo de tais elementos em uma topologia de rede. O propósito do presente artigo é discutir as duas opções clássicas e caracterizar porque uma delas se mostra a mais natural. (Não que você precise concordar comigo… :-))

Continue reading →

Segurança para Comunicações Unificadas: o que esperar do seu Firewall ?

Em um artigo anterior, apresentamos os conceitos básicos de VoIP, Telefonia IP e Colaboração (http://wp.me/p1loe7-c2) e caracterizamos o papel das redes convergentes como plataforma de negócios. Não é necessária uma longa reflexão para concluir que um tal apelo negocial vem acompanhado da necessidade de se prover segurança para o transporte integrado de vídeo, voz e dados. Seguindo o clássico raciocínio de que é recomendável criar “camadas de segurança”, resumimos a seguir algumas iniciativas relevantes no que concerne à Segurança de Telefonia IP...

Continue reading →

INTRANETS Seguras e Expansíveis com GET VPN

O termo VPN (Virtual Private Network) é utilizado para representar tecnologias que se propõem a emular as características de uma rede privada mesmo quando os dados são transportados sobre uma infra-estrutura compartilhada. A motivação comum às várias soluções de VPN é prover uma alternativa ecomonicamente viável aos circuitos dedicados de comunicação WAN, sem comprometer os aspectos de segurança.

Mas o termo segurança é abrangente e pode representar recursos bem distintos quando considerado sob a perspectiva de cada tecnologia analisada. As duas modalidades mais comuns de VPN (IPSec e MPLS-VPN) são otimizadas para resolver problemas complementares e possuem desafios também complementares.

Continue reading →

Protocolos Seguros para gerenciar sua Rede LAN

Nas comunidades de TI e Telecom é bem comum que se propague a idéia de que as disciplinas de gerenciamento e segurança de Redes são inconciliáveis (e mutuamente excludentes). Em vez de formar algum juízo de valor, entendo ser conveniente buscar soluções que mostrem que tal pessimismo não pode se perpetuar. Afinal, as redes precisam ser gerenciadas… E, se por um lado Segurança não pode ser um entrave para o gerenciamento, este último não deve inserir vulnerabilidades.

Continue reading →

RADIUS e TACACS+: dois protocolos complementares

Além de mostrar que os protocolos RADIUS e TACACS+ são complementares (e não concorrentes), o presente texto tem a intenção de esclarecer alguns erros conceituais envolvendo tais protocolos. Diante da confusão clásssica, resolvi montar uma espécie de sessão “fatos e mitos” para facilitar o entendimento:

Continue reading →

Espero que o material seja útil. Boa Leitura !

Alexandre Moraes

P.S.: Para se manter informado sobre novos artigos em Português, registre-se na página: http://facebook.com/alexandremspmoraes

CriarFaça o para criar o conteúdo