Vou fazer um novo post relacionado a Redes, especificamente para familia de roteadores CISCO. Tentei ser o mais claro possível, caso exista alguma dificuldade basta perguntar. Se preparem porque o texto é bem grande, mas procurei disponibilizar o material abordando varios tópicos.
Introdução
As Access Control Lists, também conhecidas como “access-lists” ou “ACLs”, são bastante úteis para a manipulação do tráfego, podendo ser empregadas como métodos de packet filtering (ou filtro de pacotes), policy-based routing, route-maps, class-maps, NAT/PAT, entre outras aplicações. A forma mais comum de utilização das ACLs é o filtro de pacotes padrão, o que seria um firewall básico filtrando pacotes utilizando-se do contexto de endereços de origem e destino, assim como portas de origem e destino. As access-lists podem ser configuradas para todos os protocolos roteáveis, como o TCP/IP, IPX, AppleTalk, e isto permite-nos controlar o tráfego de entrada ou saída em um roteador Cisco.
Uma access control list basicamente determina o que poderá sair ou entrar em uma determinada interface de um roteador Cisco, e o IOS faz isto para todo o pacote que estiver entrando ou saindo pela interface do equipamento.
Porque devemos utilizar Access Control Lists?
As ACLs possuem múltiplas aplicações, e o emprego destas é certamente um dos recursos mais interessantes do Cisco IOS. Por exemplo, você poderá configurar ACLs para controlar o fluxo de tráfego por aplicação existente na sua rede. Também é possível configurarmos uma Access Control List para impedir que routing updates (aqueles anúncios enviados pelos protocolos de roteamento) sejam propagados por uma determinada interface. Há ainda as situações em que você simplesmente deseja eliminar certos protocolos do seu link de WAN, e neste caso as ACLs serviriam muito bem. Note que uma access control list nem sempre possui os recursos de um firewall inteligente (ex: stateful inspection), pois estes recursos estão presentes em versões específicas do Cisco IOS.
Caso o seu IOS não seja o “Cisco IOS Firewall”, a implementação de access control lists não deverá ser feita com o propósito te proporcionar uma segurança elevada. De uma forma geral, as ACLs oferecidas pelas versões padrão do Cisco IOS (IP Plus, entre outras) são muito úteis para controlar o fluxo de tráfego ou para eliminar os protocolos desnecessários em certos segmentos de sua rede, mas não para prover uma segurança sólida.
Os cenários para a utilização de Access Control Lists são quase ilimitados. Você poderá permitir somente um host da sua rede a realizar certas tarefas ou transmitir certos protocolos, enquanto negando todo o resto. Configuração de políticas para roteamento, NAT, PAT, route-maps, entre muitos outros, são uma realidade com o esquema das Access Control Lists.
Quando devemos utilizá-las?
Assim como qualquer outro componente em uma rede, o emprego de Access Control Lists deverá ser planejado, criteriosamente. Onde se fizer necessário, uma ACL será sempre bem vinda. Caso você necessite bloquear um determinado host para o acesso à segmentos específicos da sua rede, o posicionamento correto de uma access-list oferecerá a solução mais rápida, e provavelmente a menos custosa. Caso você possua um pool de endereços IP que precisam ser traduzidos aleatoriamente em um determinado perímetro de segurança, o posicionamento de uma Access List, em conjunto com os parâmetros do NAT, oferecerá uma solução completa. Normalmente as ACLs são utilizadas em roteadores compondo o perímetro de segurança dentro da sua rede. Por mais que você disponha de firewalls dedicados, a inserção de access control lists em um roteador Cisco oferecerá uma nível de segurança adicional, garantindo ainda mais a integridade da sua rede. A utilização de Access Control Lists será sempre necessária quando você pretende manipular o tráfego utilizando recursos do Cisco IOS, conforme citamos anteriormente (route-maps, policy-map, class-map, NAT/PAT, etc), ou prover a segurança básica do seu roteador ou perímetro de segurança.
Tipos de Access Control Lists
O Cisco IOS oferece dois tipos de Access Control Lists (ou access-lists): Standard e Extended. Existem também as Access Lists conhecidas como “Advanced Access-Lists”, onde pode-se efetuar a configuração avançada para filtros de pacotes.
Configurando Access Control Lists
O objetivo deste artigo é apresentarmos as Access Lists de uma forma geral. Devido à natureza das ACLs, ficaria muito extenso se publicássemos um único artigo cobrindo todos os recursos destas. Ao invés disto, estarei mostrando somente a configuração padrão das ACLs, e em no futuro, estari publicando mais artigos sobre outras formas de utilização de ACLs e afins.
A criação de access-lists deverá ser feita por protocolo, e sempre vinculando-a à uma interface do equipamento. Para alguns protocolos, você deverá criar uma access-list para o tráfego de entrada, e uma outra access-list para o tráfego de saída. A configuração de uma ACL não é complicada, mas é sempre bom ficar atento e planejá-la antes de efetuar qualquer alteração no equipamento.
Basicamente você precisa especificar o protocolo, o número da ACL, e o critério para o filtro do pacote. As versões mais recentes do Cisco IOS suportam o que chamamos de “named access control lists”, onde você poderá nomear uma ACL, ao invés de atribuir um número para ela.
Provavelmente o maior problema com a configuração de ACLs e a enorme confusão que a wildcard mask causa em seus usuários: ao especificar o IP de origem ou destino, mais a “máscara”, muitos usuários e administradores de rede que estão começando a administrar equipamentos Cisco simplesmente colocam a máscara de subrede, ao invés do “wildcard mask”, que são coisas bem distintas. Uma “wildcard mask” é justamente o oposto da subnet-mask, e mostraremos isto mais a frente. Os seguintes protocolos suportam o recurso de “named access control lists”.
· IP
· IPX
· Apollo Domain
· ISO CNLS
· NetBIOS IPX
· Source-route bridging NetBIOS
Os números que atribuímos as access-lists determinam se a ACL será “standard” ou “extended”. Uma ACL standard informa somente o endereço de origem, o que o roteador deverá observar em cada pacote entrando ou saíndo pela sua interface, de acordo com a ACL e interface configurada. Uma ACL extended suporta endereços de origem, destino, e portas de origem ou destino, dependendo da configuração da ACL em questão. A seguinte tabela ilustra os tipos de Access Control Lists que podem ser utilizadas pelo Cisco IOS:
· IP: 1-99, 1300-1999
· Extended IP: 100-199, 2000-2699
· Ethernet type code: 200-299
· Ethernet address: 700-799
· Transparent bridging (protocol type): 200-299
· Transparent bridging (vendor code): 700-799
· Extended transparent bridging: 1100-1199
· DECnet e extended DECnet: 300-399
· XNS: 400-499
· Extended XNS: 500-599
· AppleTalk: 600-699
· Source-route bridging (protocol type): 200-299
· Source-route bridging (vendor code): 700-799
· IPX: 800-899
· Extended IPX: 900-999
· IPX SAP: 1000-1099
· Standard VINES: 1-100Extended VINES: 101-200
· Simple VINES: 201-300
Note que não é toda versão do Cisco IOS que oferece suporte à todos estes protocolos.
Wildcard Mask
Para que você possa ser bem sucedido com a configuração de ACLs, você deverá compreender por completo o que uma “wildcard mask” significa. Imagine o seguinte endereço IP e máscara de subrede: “200.157.18.200”, máscara “255.255.255.0”. O que isto significa para você? Vejamos…. você tem um endereço classe C, utilizando uma máscara padrão para esta classe (255.255.255.0). Isto indica que temos 24 bits para a porção rede, e 8 bits para a porção host. É só convertermos a máscara de subrede de decimal para binário para chegarmos à esta conclusão:
255.255.255.0 = 11111111.11111111.11111111.00000000
Os bits assinalados como “1” representam a porção rede, enquanto aqueles assinalados como “0” representam a porção host. So far, so good…
O conceito de wildcard masks implica que tudo o que for “0” deverá ser processado (ou considerado) pela ACL, enquanto os bits marcados como “1” deverão ser ignorados. É por este motivo que devemos inverter a máscara – no sentido dos bits – para podermos fazer o uso da ACL. Vejamos o mesmo exemplo agora. Se fossemos configurar uma access-control-list de forma a permitir todos os hosts da rede 200.157.18.200 para que os mesmos possam acessar uma determinada subrede em sua rede. Como faríamos isto? Se colocássemos uma wildcard mask de “255.255.255.0”, não funcionaria, pois estaríamos ignorando os três primeiros bytes do endereço IP. O que devemos fazer neste caso é informar ao roteador para processar os três primeiros bytes do endereço IP de origem de cada pacote, ignorando o quarto byte, já que o nosso objetivo é justamente permitir QUALQUER host da rede 200.157.18.200. Portanto, a configuração do critério de inspeção da ACL seria conforme:
200.157.18.0 0.0.0.255
Note que o roteador, neste caso a ACL, processaria os três primeiros bytes (marcados em verde) e ignoraria o último byte, porque neste caso a wildcard mask está composta totalmente por “1” em sua composição binária (no último byte). Lembre-se: “0” deverá se processado, “1” não será processado; simplesmente ignorado. Na verdade, tudo deverá ser processado, mas somente os “0” deverão ser considerados pela ACL.
Configuração de uma Standard Access-List
Faremos agora a configuração de uma ACL para exemplificarmos o que foi mostrado até então. Neste nosso exemplo, estaremos configurando uma standard ACL para a seguinte situação:
· Um roteador Cisco 2611. Este roteador possui 2 intefaces Ethernet, sendo que a E0/1 conecta a rede “finanças”, e a E0/0 conecta com o restante da rede.
· Cisco IOS versão 12.2(5a)
· Permitir com que todos os hosts da rede 192.168.168.0/24 passem pela interface E0/0 do Cisco 2611, rumo à rede de finanças em nosso laboratório
· Negar todo o resto: hosts não pertencentes à rede 192.168.168.0/24 não terão acesso à rede “finanças”
Note que o conceito “inbound traffic” ou “outbound traffic” está de acordo com a perspectiva do roteador, nem sempre a do administrador da rede! Quando você vincula uma ACL para uma interface de um Cisco, no sentido inbound, o roteador inspecionará os pacotes entrando por esta interface. O oposto ocorre quando o sentido é outbound. Inbound e Outbound também são conhecidos como “incoming” e “outgoing”.
1) Configuração da Standard Access Control List
É sempre recomendável que você utilize o “?” toda vez em que tiver dificuldades durante a execução dos comandos no Cisco IOS. Escolheremos a ACL número “1” para o nosso exemplo. Se você digitar “access-list ?” o IOS retornará os parâmetros válidos para o comando “access-list”.
Cisco-2611-NYC#configure terminal
Enter configuration commands, one per line. End with CNTL/Z.
Cisco-2611-NYC(config)#access-list ?
<1-99> IP standard access list
<100-199> IP extended access list
<1100-1199> Extended 48-bit MAC address access list
<1300-1999> IP standard access list (expanded range)
<200-299> Protocol type-code access list
<2000-2699> IP extended access list (expanded range)
<700-799> 48-bit MAC address access list
dynamic-extended Extend the dynamic ACL abolute timer
rate-limit Simple rate-limit specific access list
Cisco-2611-NYC(config)#access-list 1 ?
deny Specify packets to reject
permit Specify packets to forward
remark Access list entry comment
Cisco-2611-NYC(config)#access-list 1 permit ?
Hostname or A.B.C.D Address to match
any Any source host
host A single host address
Cisco-2611-NYC(config)#access-list 1 permit 192.168.168.0 ?
A.B.C.D Wildcard bits
log Log matches against this entry
Cisco-2611-NYC(config)#access-list 1 permit 192.168.168.0 0.0.0.255 ?
log Log matches against this entry
Cisco-2611-NYC(config)#access-list 1 permit 192.168.168.0 0.0.0.255
Cisco-2611-NYC(config)#
Este comando informa que configuramos uma Access List “STANDARD” (vide número “1”. De 1 à 99, as acls são standard), e que o nosso critério será “permitir todos os hosts da rede 192.168.168.0/24 (ou 255.255.255.0) para passarem pela interface”. Ainda não definimos o sentido de inspeção dos pacotes, o que faremos agora:
2) Vinculando a ACL para uma interface
Cisco-2611-NYC(config)#interface ethernet 0/0
Cisco-2611-NYC(config-if)#ip access-group 1 ?
in inbound packets
out outbound packets
Cisco-2611-NYC(config-if)#ip access-group 1 in
Cisco-2611-NYC(config-if)#exit
Cisco-2611-NYC(config)#exit
Cisco-2611-NYC#
O comando “ip access-group 1 in” informa que a ACL número “1” foi vinculada à interface (neste caso, a nossa Ethernet 0/0), para o sentido “inbound”. Os pacotes que entrarem por esta interface serão inspecionados. Agora você deve estar se perguntando: “Ok.. você só queria permitir o 192.168.168.0/24 para passar por esta interface. Mas nenhum parâmetro “deny” foi mencionado, de forma a bloquear as outras redes. Por que?”.
A resposta é que as ACLs do Cisco IOS possuem um DENY IMPLÍCITO ao final de cada ACL. É por este motivo que devemos inserir os parâmetros PERMIT primeiramente, do contrário todo o tráfego será bloqueado. No nosso exemplo, temos uma linha “permit” (para a rede 192.168.168.0/24) e um DENY IMPLÍCITO (ele não aparece, mas está por lá!), que negará todo o resto automaticamente. BE AWARE!!!
Podemos verificar a configuração da ACL e determinar se a mesma foi devidamente vinculada à interface correta, através dos seguintes comandos:
· show access-lists: Lista todas as ACLs configuradas no roteador
· show ip access-lists: Lista todas as ACLs para o protocolo IP configuradas no roteador
· show ip interface : Lista os parâmetros IP configurados para uma interface do roteador
Cisco-2611-NYC#show access-lists
Standard IP access list 1
permit 192.168.168.0, wildcard bits 0.0.0.255
Cisco-2611-NYC#show ip access-lists
Standard IP access list 1
permit 192.168.168.0, wildcard bits 0.0.0.255
Cisco-2611-NYC#
Cisco-2611-NYC#show ip int e0/0
Ethernet0/0 is up, line protocol is up
Internet address is 200.157.18.254/24
Broadcast address is 255.255.255.255
Address determined by setup command
MTU is 1500 bytes
Helper address is not set
Directed broadcast forwarding is disabled
Outgoing access list is not set
Inbound access list is 1
Proxy ARP is enabled
Security level is default
Split horizon is enabled
ICMP redirects are always sent
ICMP unreachables are always sent
ICMP mask replies are never sent
IP fast switching is enabled
IP fast switching on the same interface is disabled
IP Flow switching is disabled
IP Feature Fast switching turbo vector
IP multicast fast switching is enabled
IP multicast distributed fast switching is disabled
IP route-cache flags are Fast
Router Discovery is disabled
IP output packet accounting is disabled
IP access violation accounting is disabled
TCP/IP header compression is disabled
RTP/IP header compression is disabled
Probe proxy name replies are disabled
Policy routing is disabled
Network address translation is disabled
WCCP Redirect outbound is disabled
WCCP Redirect inbound is disabled
WCCP Redirect exclude is disabled
BGP Policy Mapping is disabled
Cisco-2611-NYC#
Como você pode notar, tudo está em ordem com a configuração da nossa ACL.
3) Configurando uma Extended Access-List
O cenário aqui será um pouco diferente. Vamos ao problema:
· Um roteador Cisco 2611. A interface Ethernet E0/1 conecta à rede “finanças”, enquanto a interface Ethernet 0/0 está conectada à outra parte da rede. O endereço da rede “finanças” é: 192.168.168.0/24.
· Cisco IOS versão 12.2(5a)
· Permitir a seguinte forma de comunicação: Todos os hosts em todas subredes poderão acessar a porta 80-TCP de todas as máquinas posicionadas dentro da rede “finanças”. Permitir, ainda, que todos os hosts da rede 192.168.150.0/24 possam acessar a porta 2001-TCP para uma máquina presente dentro da rede “finanças”, cujo endereço IP é “192.168.168.10/24”. Por último, negar todo o resto.
Cisco-2611-NYC#config terminal
Enter configuration commands, one per line. End with CNTL/Z.
Cisco-2611-NYC(config)#access-list ?
<1-99> IP standard access list
<100-199> IP extended access list
<1100-1199> Extended 48-bit MAC address access list
<1300-1999> IP standard access list (expanded range)
<200-299> Protocol type-code access list
<2000-2699> IP extended access list (expanded range)
<700-799> 48-bit MAC address access list
dynamic-extended Extend the dynamic ACL abolute timer
rate-limit Simple rate-limit specific access list
Cisco-2611-NYC(config)#access-list 100 ?
deny Specify packets to reject
dynamic Specify a DYNAMIC list of PERMITs or DENYs
permit Specify packets to forward
remark Access list entry comment
Cisco-2611-NYC(config)#access-list 100 permit ?
<0-255> An IP protocol number
ahp Authentication Header Protocol
eigrp Cisco’s EIGRP routing protocol
esp Encapsulation Security Payload
gre Cisco’s GRE tunneling
icmp Internet Control Message Protocol
igmp Internet Gateway Message Protocol
igrp Cisco’s IGRP routing protocol
ip Any Internet Protocol
ipinip IP in IP tunneling
nos KA9Q NOS compatible IP over IP tunneling
ospf OSPF routing protocol
pcp Payload Compression Protocol
pim Protocol Independent Multicast
tcp Transmission Control Protocol
udp User Datagram Protocol
Cisco-2611-NYC(config)#access-list 100 permit tcp ?
A.B.C.D Source address
any Any source host
host A single source host
Cisco-2611-NYC(config)#access-list 100 permit tcp any ?
A.B.C.D Destination address
any Any destination host
eq Match only packets on a given port number
gt Match only packets with a greater port number
host A single destination host
lt Match only packets with a lower port number
neq Match only packets not on a given port number
range Match only packets in the range of port numbers
Cisco-2611-NYC(config)#access-list 100 permit tcp any 192.168.168.0 ?
A.B.C.D Destination wildcard bits
Cisco-2611-NYC(config)#access-list 100 permit tcp any 192.168.168.0 0.0.0.255 ?
ack Match on the ACK bit
dscp Match packets with given dscp value
eq Match only packets on a given port number
established Match established connections
fin Match on the FIN bit
fragments Check non-initial fragments
gt Match only packets with a greater port number
log Log matches against this entry
log-input Log matches against this entry, including input interface
lt Match only packets with a lower port number
neq Match only packets not on a given port number
precedence Match packets with given precedence value
psh Match on the PSH bit
range Match only packets in the range of port numbers
rst Match on the RST bit
syn Match on the SYN bit
time-range Specify a time-range
tos Match packets with given TOS value
urg Match on the URG bit
Cisco-2611-NYC(config)#access-list 100 permit tcp any 192.168.168.0 0.0.0.255 eq ?
<0-65535> Port number
bgp Border Gateway Protocol (179)
chargen Character generator (19)
cmd Remote commands (rcmd, 514)
daytime Daytime (13)
discard Discard (9)
domain Domain Name Service (53)
echo Echo (7)
exec Exec (rsh, 512)
finger Finger (79)
ftp File Transfer Protocol (21)
ftp-data FTP data connections (used infrequently, 20)
gopher Gopher (70)
hostname NIC hostname server (101)
ident Ident Protocol (113)
irc Internet Relay Chat (194)
klogin Kerberos login (543)
kshell Kerberos shell (544)
login Login (rlogin, 513)
lpd Printer service (515)
nntp Network News Transport Protocol (119)
pim-auto-rp PIM Auto-RP (496)
pop2 Post Office Protocol v2 (109)
pop3 Post Office Protocol v3 (110)
smtp Simple Mail Transport Protocol (25)
sunrpc Sun Remote Procedure Call (111)
syslog Syslog (514)
tacacs TAC Access Control System (49)
talk Talk (517)
telnet Telnet (23)
time Time (37)
uucp Unix-to-Unix Copy Program (540)
whois Nicname (43)
www World Wide Web (HTTP, 80)
Cisco-2611-NYC(config)#access-list 100 permit tcp any 192.168.168.0 0.0.0.255 eq 80
Cisco-2611-NYC(config)#
O último comando mostrado no output acima reflete o primeiro de nossos problemas: todos os hosts em todas as redes poderão acessar a porta 80-TCP de todas as máquinas posicionadas dentro da rede “finanças”. Basta seguirmos a mesma linha de implantação para que possamos adicionar uma outra regra dentro da nossa estrutura “extended access-list”. Vamos a resolução do segundo problema.
Cisco-2611-NYC(config)#access-list 100 permit tcp 192.168.150.0 0.0.0.255 host 192.168.168.10 eq 2001
Este comando indica que toda a rede 192.168.150.0/24 poderá acessar a porta 2001 do host 192.168.168.10, que está localizado dentro da nossa rede “finanças”. Vamos ao terceiro problema: o DENY IMPLÍCITO se encarregará de filtrar todo o restante, mas você poderá incluir o seu próprio critério para negar tudo. Vamos aos exemplos:
Cisco-2611-NYC(config)#access-list 100 deny tcp any any log
Cisco-2611-NYC(config)#access-list 100 deny udp any any log
Cisco-2611-NYC(config)#access-list 100 deny icmp any any log
Cisco-2611-NYC(config)#access-list 100 deny ip any any log
Estes comandos rejeitarão o tráfego por blocos TCP, depois UDP, ICMP e por último IP = TUDO. Agora faremos a verificação da configuração de nossa Extended Access-List:
Cisco-2611-NYC#show access-lists
Extended IP access list 100
permit tcp any 192.168.168.0 0.0.0.255 eq www
permit tcp 192.168.150.0 0.0.0.255 host 192.168.168.10 eq 2001
deny tcp any any log
deny udp any any log
deny icmp any any log
deny ip any any log
Não se esqueça de vincular a ACL para a interface apropriada, e verificar a configuração IP desta interface logo em seguida:
Cisco-2611-NYC(config)#interface e0/0
Cisco-2611-NYC(config-if)#ip access-group 100 in
Cisco-2611-NYC(config-if)#exit
Cisco-2611-NYC(config)#exit
Cisco-2611-NYC#show ip int e0/0
Ethernet0/0 is up, line protocol is up
Internet address is 200.157.18.254/24
Broadcast address is 255.255.255.255
Address determined by setup command
MTU is 1500 bytes
Helper address is not set
Directed broadcast forwarding is disabled
Outgoing access list is not set
Inbound access list is 100
Proxy ARP is enabled
(Cortei o resto do output para evitar o desperdício de bytes!)
4) Configurando uma “Named Access Control List”
Um recurso bem interessante, disponível a partir de algumas versões do IOS 12.0 e +. Basicamente nomearemos a ACL para que o propósito desta seja facilmente identificado durante uma etapa de troubleshooting da rede. Eis o nosso cenário:
· O mesmo Cisco 2611 utilizado no exemplo anterior
· A mesma versão do Cisco IOS
· Permitir o host 192.168.157.30/24 para acessar o host 192.168.168.10/24 na porta 22-TCP (SSH)
· Permitir todos os hosts para acessarem o host 192.168.168.10/24 na porta 80-TCP (HTTP)
· Permitir todos os hosts da subrede 192.168.157.30/24 para acessarem o host 192.168.168.20/24 na porta 25 (SMTP)
· Negar todo o resto
Cisco-2611-NYC#config terminal
Enter configuration commands, one per line. End with CNTL/Z.
Cisco-2611-NYC(config)#ip access-list ?
extended Extended Access List
log-update Control access list log updates
logging Control access list logging
standard Standard Access List
Cisco-2611-NYC(config)#ip access-list extended ?
<100-199> Extended IP access-list number
WORD Access-list name
Cisco-2611-NYC(config)#ip access-list extended TESTE ?
Cisco-2611-NYC(config)#ip access-list extended TESTE
Cisco-2611-N(config-ext-nacl)#permit tcp host 192.168.157.30 host 192.168.168.10 eq 22
Cisco-2611-N(config-ext-nacl)#permit tcp any host 192.168.168.10 eq 80
Cisco-2611-N(config-ext-nacl)#permit tcp 192.168.157.0 0.0.0.255 host 192.168.168.20 eq 25
Cisco-2611-N(config-ext-nacl)#deny ip any any
Cisco-2611-N(config-ext-nacl)#exit
Cisco-2611-NYC(config)#exit
Agora verificaremos a configuração de nossa “Named Access-List”. Note que esta ACL foi configurada como “EXTENDED”.
Cisco-2611-NYC#show access-lists
Extended IP access list TESTE
permit tcp host 192.168.157.30 host 192.168.168.10 eq 22
permit tcp any host 192.168.168.10 eq www
permit tcp 192.168.157.0 0.0.0.255 host 192.168.168.20 eq smtp
deny ip any any
5) Configurando Access-List para LINE VTY
Uma forma de proteger o seu LINE VTY (sessões telnet para o roteador), equanto permitindo que o tráfego telnet possa passar pelas interfaces de seu roteador. Neste caso, criaremos uma simples “standard access-list”, e informaremos os “sources” que poderão efetuar o telnet para os line vty de nosso equipamento Cisco. Isto pode ser feito com uma “standard access-list” comum.
Cisco-2611-NYC(config)#ip access-list standard ?
<1-99> Standard IP access-list number
WORD Access-list name
Cisco-2611-NYC(config)#access-list 2 permit 192.168.168.1
Cisco-2611-NYC(config)#access-list 2 permit 192.168.168.2
Cisco-2611-NYC(config)#access-list 2 deny any
No exemplo anterior, estamos permitindo os hosts “192.168.168.1” e “192.168.168.2” para que estes possam efetuar sessões telnet PARA o roteador. Todo o resto será negado, ou seja, sem condições de acessarem o terminal Cisco. Agora vincularemos esta ACL para o LINE VTY:
Cisco-2611-NYC(config)#line vty 0 4
Cisco-2611-NYC(config-line)#access-class ?
<1-199> IP access list
<1300-2699> IP expanded access list
Cisco-2611-NYC(config-line)#access-class 2 in
Cisco-2611-NYC(config-line)#
6) Configurando Access-List para restringir o acesso SNMP ao roteador Cisco
As ACLs também são úteis para restringir a utilização do SNMP nos seus roteadores Cisco. Todos nós sabemos que existem tubos e tubos de ferramentas na Internet (veja o próprio exemplo do SolarWinds Engineer’s Edition), que fazem brute force attacks contra equipamentos de rede com SNMP configurado. Estas ferramentas ficam tentando, incessantemente, descobrir as communities read-only, read-write, read-write-all, etc, de seus equipamentos de rede. Uma vez descobertas, o hacker terá todo acesso a configuração de seu equipamento, além de poder utilizar ferramentas adicionais para mapear toda a sua rede, facilitando ainda mais as possibilidades de invasão e comprometimento da rede. Neste nosso exemplo, utilizaremos a mesma ACL configurada no exemplo anterior (ACL# 2), e vincularemos esta ACL para as communities SNMP em nosso equipamento Cisco.
Cisco-2611-NYC(config)#snmp-server community informeaquiacommunityRO ro ?
<1-99> Std IP accesslist allowing access with this community string
<1300-1999> Expanded IP accesslist allowing access with this community
string
Cisco-2611-NYC(config)#snmp-server community informeaquiacommunityRO ro 2
Cisco-2611-NYC(config)#snmp-server community informeaquiacommunityRW rw 2
Basicamente isto aí… utilizamos a mesma ACL criada anteriormente, e atribuimos esta ACL para as communities read-only e read-write de nosso equipamento Cisco. Suponhamos que os hosts 192.168.168.1 e 192.168.168.2, especificados na ACL# 2, fossem as nossas estações de gerenciamento da rede (NMS), rodando SNMP. Somente estes hosts poderão fazer consultas SNMP para o roteador. Capiche?
7) Regras e Considerações para o posicionamento de Access Control Lists para TCP/IP
Como tudo nesta vida há um preço, a utilização de ACLs também tem o seu: performance. Um roteador configurado com access control lists gastará mais ciclos de sua CPU para processar os pacotes entrando e saíndo pelas suas interfaces. O motivo é até óbvio, uma vez que o roteador terá que pesquisar por instruções adicionais no pacote, antes de efetuar o “path determination” e o “packet switching”. Portanto, muito cuidado quando você decidir-se pela implementação de access-lists. Eis algumas dicas:
· Agrupe as regras por protocolos: Configure e agrupe as regras TCP, todas de uma vez só. Faça o mesmo com relação ao filtro UDP, criando e alocando linha por linha somente para o UDP. Em seguida, faça o mesmo para ICMP. Isto fará com que o roteador gaste menos ciclos de CPU procurando pelas regras.
· Coloque as regras com maior índice de acertos ao topo da ACL: A pesquisa é sempre efetuada de CIMA para BAIXO. Uma vez que o roteador encontrou uma linha na ACL que combina exatamente com a descrição do pacote, o roteador processará o pacote e não mais pesquisará pelas demais linhas da ACL. Se você posicionar as regras com maior índice de acertos (ou matches) primeiramente (ao topo da ACL), o roteador gastará menos ciclos de CPU, consequentemente.
· Coloque as regras PERMIT primeiro, depois as DENY: Uma vez que a Access List possui um DENY IMPLÍCITO ao final da ACL, fica mais óbvio e prudente configurar as regras “permit” ao topo de cada bloco em sua ACL (TCP, UDP, ICMP, IP).
· Utilize um editor de textos (copy & paste para o Notepad?): Antes de fazer qualquer alteração em um ambiente de produção, procure copiar toda a ACL para dentro do seu bloco de notas (qualquer editor de textos), e faça as alterações no editor de textos. Faça ainda uma revisão de todas as regras, e somente após isto copie-as de volta para o roteador. Isto eliminará bastante a possibilidade de erros e as tarefas de configuração serão menos tediosas.
Bom demorou bastante para escrever, e postar.
Ufa, acabou, até a proxima.
Moedor de Cana 