Статья в MikroTik Wiki об IPSec

MikroTik router to CISCO PIX Firewall IPSEC

Contents 1 How to interconnect two networks with IPSec between Mikrotik ROS and Cisco PIX 1.1 Configuration of router running Mikrotik RouterOS 1.2 Cisco PIX Firewall configuration 1.3 Corresponding Cisco Router configuration

How to interconnect two networks with IPSec between Mikrotik ROS and Cisco PIX

This example shows how to interconnect remote offices uses IPSec VPN between Mikrotik RouterOS device and Cisco PIX Firewall or Cisco Router, running Cisco IOS. Also I show you how to provide Internet access for network using masquerade/PAT on Mikrotik RouterOS, Cisco PIX Firewall and Cisco Router, running Cisco IOS. Network topology is shown below. We would like to interconnect networks 172.22.1.1/24 and 172.22.2.1/24 using corresponding public addresses 1.0.0.2 and 2.0.0.2. Assume 1.0.0.1 is default gateway for router, running Mikrotik RouterOS and 2.0.0.1 is default gateway for router running Cisco IOS or Cisco PIX Firewall, running Cisco PIX OS. This configuration tested and works well with Mikrotik RouterOS 3.20, Cisco IOS 12.4(21) and 12.3(26) advanced security features set with encryption and PIX OS 6.3(5).

Configuration of router running Mikrotik RouterOS

This configuration is simple and very similar to official 3.0 ipsec manual page

Mikrotik Router

Add addresses on interfaces

[admin@Mikrotik] > ip address add \
 address=1.0.0.2/30 broadcast=1.0.0.3 disabled=no \
 interface=public network=1.0.0.0
[admin@Mikrotik] > ip address add \
 address=172.22.1.1/24 broadcast=172.22.1.255 disabled=no \
 interface=inside network=172.22.1.0

Add ip routes

[admin@Mikrotik] > ip route add \
 disabled=no distance=1 dst-address=0.0.0.0/0 gateway=1.0.0.1 \
 scope=30 target-scope=10

Add accept and masquerading rules in SRC-NAT

[admin@Mikrotik] > ip firewall nat add \
 chain=srcnat \
 src-address=172.22.1.0/24 \
 dst-address=172.22.2.0/24 action=accept

[admin@Mikrotik] > ip firewall nat add \
 chain=srcnat out-interface=public action=masquerade

Add peer (with phase1 configuration parameters), DES and SHA1 will be used to protect IKE traffic for MikroTik router

[admin@MikroTik] > ip ipsec peer add \
 address=2.0.0.2 secret="gvejimezyfopmekun" enc-algorithm=des

Set encryption proposal (phase2 proposal - settings that will be used to encrypt actual data) to use DES to encrypt data for MikroTik router

[admin@MikroTik] > ip ipsec proposal set default enc-algorithms=des

Add policy rule that matches traffic between subnets and requires encryption with ESP in tunnel mode for MikroTik router

[admin@MikroTik] > ip ipsec policy add \
 src-address=172.22.2.0/24 \
 dst-address=172.22.1.0/24 \
 action=encrypt \
 tunnel=yes sa-src=1.0.0.2 sa-dst=2.0.0.2

Add firewall rules to permit VPN traffic and private traffic

[admin@Mikrotik] >ip firewall add \
 action=accept chain=input disabled=no protocol=ipsec-esp src-address=2.0.0.2

[admin@Mikrotik] >ip firewall add \
 action=accept chain=customer disabled=no dst-address=172.22.1.0/24 \
 in-interface=public out-interface=inside src-address=172.22.2.0/24

Cisco PIX Firewall configuration

I think this configuration is quiet clear because of detailed comments.

Cisco PIX Firewall

    PIX Version 6.3(5)
   nameif ethernet0 outside security0
   nameif ethernet1 inside security100
   !
   !--- Create access list that matches traffic that should be encrypted (traffic to RouterOS device)
   access-list myacl permit ip 172.22.2.0 255.255.255.0 172.22.2.0 255.255.255.0
   !
   !---  Create access list that matches traffic that should not be NATed (traffic to RouterOS device)
   access-list nonat permit ip 172.22.2.0 255.255.255.0 172.22.1.0 255.255.255.0
   !
   !--- Configuring NAT
   ip address outside 2.0.0.2 255.255.255.252
   ip address inside 172.22.2.1 255.255.255.0
   !
   global (outside) 1 2.0.0.2
   !
   !--- Do not make NAT for traffic to RouterOS device
   nat (inside) 0 access-list nonat
   nat (inside) 1 172.22.2.0 255.255.255.0 0 0
   !
   route outside 0.0.0.0 0.0.0.0 2.0.0.1 1
   !
   sysopt connection permit-ipsec
   !
   !--- Create IPsec transform set - transformations that should be applied to
   !--- traffic - ESP encryption with DES and ESP authentication with SHA1
   !--- This must match "/ip ipsec proposal"
   crypto ipsec transform-set myset esp-des esp-sha-hmac
   crypto ipsec security-association lifetime seconds 1800
   !
   !--- Create crypto map that will use transform set "myset", use peer 1.0.0.2
   !--- to establish SAs and encapsulate traffic and use access-list myacl to
   !--- match traffic that should be encrypted
   crypto map mymap 21 ipsec-isakmp
   crypto map mymap 21 match address myacl
   crypto map mymap 21 set peer 1.0.0.2
   crypto map mymap 21 set transform-set myset
   crypto map mymap interface outside
   !
   !--- Configure ISAKMP policy (phase1 config, must match configuration
   !--- of "/ip ipsec peer" on RouterOS).
   isakmp enable outside
   !--- Add preshared key to be used when talking to RouterOS
   isakmp key gvejimezyfopmekun address 1.0.0.2 netmask 255.255.255.255
   isakmp identity address
   isakmp policy 20 authentication pre-share
   isakmp policy 20 encryption des
   isakmp policy 20 hash md5
   isakmp policy 20 group 2
   : end

---

Corresponding Cisco Router configuration

This configuration is just for example. You can use Cisco router instead Cisco PIX Firewall.

Cisco Router

    !--- Configure ISAKMP policy (phase1 config, must match configuration
   !--- of "/ip ipsec peer" on RouterOS). Note that DES is default
   !--- encryption algorithm on Cisco. SHA1 is default authentication
   !--- algorithm
   crypto isakmp policy 20
     authentication pre-share
     hash md5
     exit
   !
   !--- Add preshared key to be used when talking to RouterOS
   crypto isakmp key gvejimezyfopmekun address 1.0.0.2
   !   
   ! Create IPsec transform set - transformations that should be applied to
   ! traffic - ESP encryption with DES and ESP authentication with SHA1
   ! This must match "/ip ipsec proposal"
   crypto ipsec transform-set myset esp-des esp-sha-hmac
     mode tunnel                                  
     exit
   !
   !
   !--- Create crypto map that will use transform set "myset", use peer 1.0.0.2
   !--- to establish SAs and encapsulate traffic and use access-list 101 to
   !--- match traffic that should be encrypted
   crypto map mymap 21 ipsec-isakmp
     set peer 1.0.0.2
     set transform-set myset
     set pfs group2
     match address 101
     exit
   !
   !
   !--- And finally apply crypto map to outside interface
   interface Ethernet0
   ip address 2.0.0.2 255.255.255.252
   no ip directed-broadcast
   ip nat outside
   crypto map mymap
   !
   interface Ethernet1
   ip address 172.22.2.1 255.255.255.0
   no ip directed-broadcast
   ip nat inside
   !
   !
   !--- Create NAT pool
   ip nat pool mypool 2.0.0.2 2.0.0.2 netmask 255.255.255.252
   !
   !--- Do not make NAT for traffic to RouterOS device
   ip nat inside source route-map nonat pool mypool overload
   ip classless
   ip route 0.0.0.0 0.0.0.0 2.0.0.1
   !
   !---  Create access list that matches traffic that should be encrypted (traffic to RouterOS device)
   access-list 101 permit ip 172.22.2.0 0.0.0.255 172.22.1.0 0.0.0.255
   !
   !---  Create access list that matches traffic that should not be NATed (traffic to RouterOS device):
   access-list 102 deny   ip 172.22.2.0 0.0.0.255 172.22.1.0 0.0.0.255
   access-list 102 permit ip 172.22.2.0 0.0.0.255 any
   !
   !--- Create route-map for traffic that should be NATed
   route-map nonat permit 10
   match ip address 102
   !   
   end

Статья про IPSec в MikroTik Wiki от меня

Вчера написал статью для Wiki от производителя нашего оборудования Mikrotik. Скорее всего будет интересна не только для пользователей их ОС RouterOS, но и для тех, кто имеет в своём арсенале PIX Firewall или маршрутизатор Cisco и желает объеденить несколько офисов в одну сеть. Собственно, статья:

MikroTik router to CISCO PIX Firewall IPSEC

• Содержание1 How to interconnect two networks with IPSec between Mikrotik ROS and Cisco PIX
  1.1 Configuration of router running Mikrotik RouterOS
  1.2 Cisco PIX Firewall configuration
  1.3 Corresponding Cisco Router configuration

How to interconnect two networks with IPSec between Mikrotik ROS and Cisco PIX

This example shows how to interconnect remote offices uses IPSec VPN between Mikrotik RouterOS device and Cisco PIX Firewall or Cisco Router, running Cisco IOS. Also I show you how to provide Internet access for network using masquerade/PAT on Mikrotik RouterOS, Cisco PIX Firewall and Cisco Router, running Cisco IOS. Network topology is shown below. We would like to interconnect networks 172.22.1.1/24 and 172.22.2.1/24 using corresponding public addresses 1.0.0.2 and 2.0.0.2. Assume 1.0.0.1 is default gateway for router, running Mikrotik RouterOS and 2.0.0.1 is default gateway for router running Cisco IOS or Cisco PIX Firewall, running Cisco PIX OS. This configuration tested and works well with Mikrotik RouterOS 3.20, Cisco IOS 12.4(21) and 12.3(26) advanced security features set with encryption and PIX OS 6.3(5).

Configuration of router running Mikrotik RouterOS

This configuration is simple and very similar to official 3.0 ipsec manual page
Mikrotik Router
Add addresses on interfaces

   [admin@Mikrotik] > ip address
add address=1.0.0.2/30 broadcast=1.0.0.3 comment="" disabled=no interface=\
public network=1.0.0.0
[admin@Mikrotik] > ip address
add address=172.22.1.1/24 broadcast=172.22.1.255 comment="" disabled=no \
interface=inside network=172.22.1.0

Add ip routes

   [admin@Mikrotik] > ip route
add comment="" disabled=no distance=1 dst-address=0.0.0.0/0 gateway=1.0.0.1 \
scope=30 target-scope=10

Add accept and masquerading rules in SRC-NAT

    [admin@Mikrotik] > ip firewall nat add chain=srcnat src-address=172.22.1.0/24 \
\... dst-address=172.22.2.0/24 action=accept
[admin@Mikrotik] > ip firewall nat add chain=srcnat out-interface=public \
\... action=masquerade

Add peer (with phase1 configuration parameters), DES and SHA1 will be used to protect IKE traffic for MikroTik router

    [admin@MikroTik] > ip ipsec peer add address=2.0.0.2 \
\... secret="gvejimezyfopmekun" enc-algorithm=des

Set encryption proposal (phase2 proposal - settings that will be used to encrypt actual data) to use DES to encrypt data for MikroTik router

    [admin@MikroTik] > ip ipsec proposal set default enc-algorithms=des

Add policy rule that matches traffic between subnets and requires encryption with ESP in tunnel mode for MikroTik router

    [admin@MikroTik] > ip ipsec policy add \
\... src-address=172.22.1.0/24 dst-address=172.22.2.0/24 action=encrypt \
\... tunnel=yes sa-src=1.0.0.2 sa-dst=2.0.0.2

---

Cisco PIX Firewall configuration

I think this configuration is quiet clear because of detailed comments.
Cisco PIX Firewall

    PIX Version 6.3(5)
nameif ethernet0 outside security0
nameif ethernet1 inside security100
!
!--- Create access list that matches traffic that should be encrypted (traffic to RouterOS device)
access-list myacl permit ip 172.22.2.0 255.255.255.0 172.22.2.0 255.255.255.0
!
!---  Create access list that matches traffic that should not be NATed (traffic to RouterOS device)
access-list nonat permit ip 172.22.2.0 255.255.255.0 172.22.1.0 255.255.255.0
!
!--- Configuring NAT
ip address outside 2.0.0.2 255.255.255.252
ip address inside 172.22.2.1 255.255.255.0
!
global (outside) 1 2.0.0.2
!
!--- Do not make NAT for traffic to RouterOS device
nat (inside) 0 access-list nonat
nat (inside) 1 172.22.2.0 255.255.255.0 0 0
!
route outside 0.0.0.0 0.0.0.0 2.0.0.1 1
!
sysopt connection permit-ipsec
!
!--- Create IPsec transform set - transformations that should be applied to
!--- traffic - ESP encryption with DES and ESP authentication with SHA1
!--- This must match "/ip ipsec proposal"
crypto ipsec transform-set myset esp-des esp-sha-hmac
crypto ipsec security-association lifetime seconds 1800
!
!--- Create crypto map that will use transform set "myset", use peer 1.0.0.2
!--- to establish SAs and encapsulate traffic and use access-list myacl to
!--- match traffic that should be encrypted
crypto map mymap 21 ipsec-isakmp
crypto map mymap 21 match address myacl
crypto map mymap 21 set peer 1.0.0.2
crypto map mymap 21 set transform-set myset
crypto map mymap interface outside
!
!--- Configure ISAKMP policy (phase1 config, must match configuration
!--- of "/ip ipsec peer" on RouterOS).
isakmp enable outside
!--- Add preshared key to be used when talking to RouterOS
isakmp key gvejimezyfopmekun address 1.0.0.2 netmask 255.255.255.255
isakmp identity address
isakmp policy 20 authentication pre-share
isakmp policy 20 encryption des
isakmp policy 20 hash md5
isakmp policy 20 group 2
: end

---

Corresponding Cisco Router configuration

This configuration is just for example. You can use Cisco router instead Cisco PIX Firewall.
Cisco Router

    !--- Configure ISAKMP policy (phase1 config, must match configuration
!--- of "/ip ipsec peer" on RouterOS). Note that DES is default
!--- encryption algorithm on Cisco. SHA1 is default authentication
!--- algorithm
crypto isakmp policy 20
authentication pre-share
hash md5
exit
!
!--- Add preshared key to be used when talking to RouterOS
crypto isakmp key gvejimezyfopmekun address 1.0.0.2
!
! Create IPsec transform set - transformations that should be applied to
! traffic - ESP encryption with DES and ESP authentication with SHA1
! This must match "/ip ipsec proposal"
crypto ipsec transform-set myset esp-des esp-sha-hmac
mode tunnel                       
exit
!
!
!--- Create crypto map that will use transform set "myset", use peer 1.0.0.2
!--- to establish SAs and encapsulate traffic and use access-list 101 to
!--- match traffic that should be encrypted
crypto map mymap 21 ipsec-isakmp
set peer 1.0.0.2
set transform-set myset
set pfs group2
match address 101
exit
!
!
!--- And finally apply crypto map to outside interface
interface Ethernet0
ip address 2.0.0.2 255.255.255.252
no ip directed-broadcast
ip nat outside
crypto map mymap
!
interface Ethernet1
ip address 172.22.2.1 255.255.255.0
no ip directed-broadcast
ip nat inside
!
!
!--- Create NAT pool
ip nat pool mypool 2.0.0.2 2.0.0.2 netmask 255.255.255.252
!
!--- Do not make NAT for traffic to RouterOS device
ip nat inside source route-map nonat pool mypool overload
ip classless
ip route 0.0.0.0 0.0.0.0 2.0.0.1
!
!---  Create access list that matches traffic that should be encrypted (traffic to RouterOS device)
access-list 101 permit ip 172.22.2.0 0.0.0.255 172.22.1.0 0.0.0.255
!
!---  Create access list that matches traffic that should not be NATed (traffic to RouterOS device):
access-list 102 deny   ip 172.22.2.0 0.0.0.255 172.22.1.0 0.0.0.255
access-list 102 permit ip 172.22.2.0 0.0.0.255 any
!
!--- Create route-map for traffic that should be NATed
route-map nonat permit 10
match ip address 102
!
end

Получено с http://wiki.mikrotik.com/wiki/MikroTik_router_to_CISCO_PIX_Firewall_IPSEC

Категории: VPN Firewall

Настраиваем неприступный маршрутизатор. Часть 2

Статья была опубликована в журнале IT-Спец за апрель 2008 г.
В прошлой части статьи мы начали настраивать безопасность маршрутизатора с ограничения доступа непосредственно к самому устройству, отключили лишние службы, настроили безопасность SNMP и включили журналирования. Остановились мы на аспекте безопасного межсетевого взаимодействия, которое, подчас, является не менее важным чем безопасность самого маршрутизатора.

1.Защита от подмены ip-адресов или антиспуфинг

Подмена ip-адресов - это настоящий бич интернета, основанного на потоколе ip версии 4. Проблема состоит в том, что чаще всего большинство маршрутизаторов настроены на перенаправление пакетов исходя только из данных в поле адреса назначения заголовка ip. Конечно, проблема заключается не в самом механизме маршрутизации, а в том, что в большинстве сетей абсолютно любой корректно сформированный пакет будет совершенно свободно перенаправлен, если маршрутизатор будет иметь маршрут к адресу назначения, даже если в поле адреса источника заголовка ip будет указан нелегитимный адрес. Подобный нелегитимный (фейк) адрес в условиях нормально функционирования сети обычно не может быть указан в качестве источника пакета и чаще всего причиной его появления может стать лишь то, что кто-то, а точнее что-то не желает показать, откуда в действительности пришел пакет. Проще говоря, причиной появления в сети подобных пакетов чаще всего является вредоносное программное обеспечение, будь то черви, вирусы, спам- или DDoS-боты. Конечно, скрыть их деятельность очень сложно и любой мало-мальски опытный сетевой администратор при желании достаточно быстро обнаружит их сетевую активность. Возьмем, к примеру, процесс рассылки спама. Пусть в данном примере схема сети в точности соответствует рисунку. Чаще всего такой нехорошей затеей, т.е. спамом, будут заниматься управляемые боты, особый класс вредоносного программного обеспечения типа троянов-бекдоров, централизованно управляемых с мастер-сервера. Спам-бот, получив команду от хозяина через мастер-сервер в большом количестве рассылает корреспонденцию, открывая множество tcp-соединений на 25-е порты (SMTP) различных серверов. При этом в кеше маршрутизатора сетевой администратор наблюдает записи подобные этим:

#show ip cash flow
E0/0 86.35.180.4 E0/1 72.80.182.193 06 0C17 0019 7

E0/0 92.83.36.64 E0/1 78.37.213.158 06 E774 0019 2

E0/0 85.140.144.55 E0/1 78.37.213.158 06 CB6A 0019 7

E0/0 88.231.190.7 E0/1 69.13.131.2 06 C211 0019 2

E0/0 83.143.38.195 E0/1 67.18.144.162 06 0C37 0019 2

E0/0 62.66.167.235 E0/1 44.98.128.241 06 714F 0019 6


здесь 0019 - 25-й порт в шестнадцатеричном представлении. Администратор видит, что с интерфейса E0/1, который является в нашем примере внутренним, в большом количестве поступают пакеты, направленные к адресам в интернете, а порт назначения принадлежит протоколу SMTP. Однако, адрес источника никак не мог оказаться таким, ведь внутрення подсеть 121.132.143.0/24! Что же случилось? Мы столкнулись с простейшим примером подмены адреса источника или, проще говоря, спуфинга. Что же делать? Вариантов защиты несколько. Первый из них - ограничить исходящие пакеты на основе ip-адреса источника, исходя из принадлежности адресов к нашей сети:

#conf t
(config)#ip access-list standart 20
(config-std-nacl)#permit 121.132.143.0 0.0.0.255
(config-std-nacl)#deny any
(config-std-nacl)#exit
(config)#interface E0/1
(config-if)#ip access-group 20 in


Таким образом мы ограничим исходящий трафик из нашей сети с адресов, которые фактически нам не принадлежат. Такая концепция как минимум облегчит жизнь таким же как мы сетевым администраторам в деле борьбы с подменой ip-адресов. Теперь перейдем к внешнему интерфейсу. Согласно нашему примеру это интерфейс E0/0. Ограничим входящий трафик с адресов, которые фактически не могут быть источниками для пакетов, приходящих из интернета. Естественно, из внешней сети к нам не могут прийти пакеты, источник которых - наша внутренняя сеть, ограничим их:

#conf t
(config)#ip access-list standart 30
(config-std-nacl)#deny ip 121.132.143.0 0.0.0.255

Затем ограничим адреса, которые согласно RFC 1918 являются «серыми», т.е. немаршрутизируемыми в интернете:

(config-std-nacl)#deny ip 10.0.0.0 0.255.255.255
(config-std-nacl)#deny ip 172.16.0.0 0.15.255.255
(config-std-nacl)#deny ip 192.168.0.0 0.0.255.255

Кроме того, можно заблокировать адреса, являющиеся адресами автоконфигурации. Такие адреса, например, присваиваются компьютерам под управлением операционной системы Windows, настройки сетевого подключения которого обеспечивают присвоение адресов по протоколу DHCP, если в данный момент присвоить адрес не удается (допустим, не доступен dhcp-сервер):

(config-std-nacl)#deny ip 169.254.0.0 0.0.255.255

Ограничим адреса multicast (класс D) и адреса, предназначенные для последующего использования (класс E):

(config-std-nacl)#deny ip 224.0.0.0 15.255.255.255
(config-std-nacl)#deny ip 240.0.0.0 7.255.255.255

Адреса, принадлежащие интерфейсу обратной петли (loopback) и адреса, первые октеты которых нули или все единицы также заблокируем, ибо путь их следования сомнителен:

(config-std-nacl)#deny ip 127.0.0.0 0.255.255.255
(config-std-nacl)#deny ip 0.0.0.0 0.255.255.255
(config-std-nacl)#deny ip host 255.255.255.255

Подсеть, предназначенную для тестирования заблокируем аналогично предыдущим:

(config-std-nacl)#deny ip 192.0.2.0 0.0.0.255

Ну и напоследок ограничим адреса, зарезервированные за организацией IANA и/или так называемые bogons-адреса:

(config-std-nacl)#deny ip 1.0.0.0 0.255.255.255
deny ip 2.0.0.0 0.255.255.255
deny ip 5.0.0.0 0.255.255.255
deny ip 14.0.0.0 0.255.255.255
deny ip 23.0.0.0 0.255.255.255
deny ip 27.0.0.0 0.255.255.255
deny ip 31.0.0.0 0.255.255.255
deny ip 36.0.0.0 0.255.255.255
deny ip 37.0.0.0 0.255.255.255
deny ip 39.0.0.0 0.255.255.255
deny ip 42.0.0.0 0.255.255.255
deny ip 46.0.0.0 0.255.255.255
deny ip 49.0.0.0 0.255.255.255
deny ip 50.0.0.0 0.255.255.255
deny ip 100.0.0.0 0.255.255.255
deny ip 101.0.0.0 0.255.255.255
deny ip 102.0.0.0 0.255.255.255
deny ip 103.0.0.0 0.255.255.255
deny ip 104.0.0.0 0.255.255.255
deny ip 105.0.0.0 0.255.255.255
deny ip 106.0.0.0 0.255.255.255
deny ip 107.0.0.0 0.255.255.255
deny ip 108.0.0.0 0.255.255.255
deny ip 109.0.0.0 0.255.255.255
deny ip 110.0.0.0 0.255.255.255
deny ip 111.0.0.0 0.255.255.255
deny ip 112.0.0.0 0.255.255.255
deny ip 113.0.0.0 0.255.255.255
deny ip 175.0.0.0 0.255.255.255
deny ip 176.0.0.0 0.255.255.255
deny ip 177.0.0.0 0.255.255.255
deny ip 178.0.0.0 0.255.255.255
deny ip 179.0.0.0 0.255.255.255
deny ip 180.0.0.0 0.255.255.255
deny ip 181.0.0.0 0.255.255.255
deny ip 182.0.0.0 0.255.255.255
deny ip 183.0.0.0 0.255.255.255
deny ip 184.0.0.0 0.255.255.255
deny ip 185.0.0.0 0.255.255.255
deny ip 197.0.0.0 0.255.255.255
deny ip 223.0.0.0 0.255.255.255

Не забываем:
permit ip any

Собственно, теперь требуется применить список доступа к интерфейсу:

(config-std-nacl)#exit
(config)#interface E0/0
(config-if)#
ip access-group 20 in

Естественно, с таким же успехом мы могли бы отправлять подобные пакеты в «черную дыру», настроив соответствующим образом маршруты, например, для подсети 192.168.0.0/24 так:

(config)#interface Null0
(config-if)#exit
(config)#ip route 192.168.0.0 255.255.255.0 Null0

Как упоминалось выше, путей решения проблемы спуфинга может быть несколько, и вторая из них - использования протокола Cisco Express Forwarding, особого протокола уровня 3, предназначенного для ускоренной коммутации пакетов и используемого в больших ядрах сети. Наша цель его применения будет заключаться в контролировании обратного пути следования пакета, пришедшего на интерфейс с помощью команды конфигурации интерфейса «ip verify unicast
reverse-path». Однако, здесь может быть несколько сложностей, основная из которых - ограничение, заключающееся в необходимости наличия симметричного прямого и обратного пути пакета. В обратном случае маршрутизация может быть нарушена. Проще говоря, я Вас предупредил - будьте осторожны в своих экспериментах. Последнее, что хотелось бы порекомендовать - запретить принимать фрагментированные icmp-пакеты, хотя атаки, основанные на их использовании и потеряли свою актуальность, лишним это не будет:

deny icmp any any fragments


2.Защита от DDoS

Перейдем ко второй части настройке безопасного межсетевого взаимодействия, а именно к защите от распределенных атак отказа в обслуживании, направленных на истощение ресурсов сети. Как известно, в последнее время атаки типа TCP SYN-flood постепенно сходят на нет благодаря стараниям корпорации Microsoft по защите своих операционных систем семейства Windows от бесконтрольного использования сырых сокетов, позволяющих конструировать сетевые пакеты «вручную». Ввиду вышеназванных обстоятельств все большую популярность приобретают атаки типа ICMP/UDP флуд или атаки, направленные на отказ в обслуживании Web-сервисов путем перегрузки POST/GET-запросами. Как и в любом деле, вариантов выхода из ситуации может быть несколько, но всегда есть наиболее простой. Пойдем по пути наименьшего сопротивления и будем пресекать выше названые атаки с помощью QoS. Суть защиты будет состоять в ограничении пропускной способности, доступной для различных сетевых протоколов. Конечно, параметры очередей будут сильно зависеть от общей пропускной способности вашей сети и статистического распределения трафика по типам. Пусть внешний интерфейс имеет канал 10 Mb/s. Для примера поступим следующим образом: ограничим ICMP-трафик до 500 Kb/s, а UDP-трафик - до 2 Mb/s.

!
interface Ethernet0/0
rate-limit input access-group 150 2010000 250000 250000 conform-action transmit exceed-action drop
rate-limit input access-group 160 500000 62500 62500 conform-action transmit exceed-action drop
...

Если бы в нашей сети использовалась многоадресная рассылка, то можно было бы ограничить и ее, допустим, потоком в 2,5 Mb/s:

rate-limit input access-group 170 2500000 187500 187500 conform-action transmit exceed-action drop

Собственно, списки доступа, согласно которым мы будем классифицировать трафик:

!
access-list 150 remark CAR-UDP ACL
access-list 150 permit udp any any
access-list 160 remark CAR-ICMP ACL
access-list 160 permit icmp any any
access-list 170 remark CAR-Multicast ACL
access-list 170 permit ip any 224.0.0.0 15.255.255.255
!

Опять же в плане защиты от DDoS есть еще варианты, один из которых - перехватчики TCP, которые являются достаточно эффективным средством, но относятся только к атаке TCP SYN-flood, направленной на истощение ресурсов системы. Суть работы перехватчиков TCP заключается в том, что маршрутизатор будет выступать неким посредником между сервером, предоставляющим какую-либо службу TCP и клиентом, пытающимся установить соединение. Идея чрезвычайно проста - маршрутизатор, получивший SYN (synchronization) -пакет в ответ на него пытается отправить ответ SYN/ACK к источнику т.е клиенту. Если операция выполняется успешно, маршрутизатор устанавливает соединение с сервером, а затем объединяет воедино оба соединения. Далее сервер и клиент продолжают процесс взаимодействия без участия маршрутизатора. В результате, если SYN-пакет приходит от недостижимого источника, сервер никогда не узнает о том, что была попытка открытия подключения. Перехватчики TCP могут работать в двух режимах: пассивном режиме наблюдения и, собственно, активном - перехвата. По умолчанию перехватчики работают во втором. Процесс настройки банален и прост, сводится он к указанию списка серверов, соединения с которыми требуется перехватывать и введению команды глобальной конфигурации, задействующей перехватчики для заданного списка доступа:

ip tcp intercept list 101

!

access-list 101 permit tcp any 121.132.143.0 0.0.0.255

3.Комплексная защита внутренней сети
Перейдем к последнему пункту безопасного сетевого взаимодействия - комплексной защите внутренней сети. Основным функционалом, используемым нами будет контекстный контроль доступа (Context-Based Access Control
), входящий в состав Cisco IOS Firewall. Вкратце, использование CBAC позволяет обойти ограничения, заложенные в фильтрацию на основе списков доступа, исходя из того, что в отличие от списков доступа, CBAC оперирует не только информацией сетевого уровня, но и, отчасти, уровня приложения. Основной критерий, на котором базируется CBAC является понятие сессии. Исходя из нее, обратный трафик, который в ситуации использования обычного списка доступа должен был бы быть заблокирован, будет пропущен с помощью создания временных разрешающих записей в списке доступа. Проще говоря, все то, что было инициировано и относится к текущей сессии изнутри, вернется обратно, в то время как аналогичные типы трафика извне не будет пропущены. Однако, внимательный читатель мог заметить, что фактически подобное поведение аналогично состояниям соединений related/established:

permit tcp host 192.168.0.5 eq www any established

но прав он будет лишь отчасти, т.к. CBAC имеет намного больший спектр функционала, и способен различить сессии даже мультимедийных протоколов типа H.323, RealAudio, не говоря уже о таких обыденных протоколах как SMTP или FTP. Впрочем, не будем углубляться в подробности, тем более что в любой момент читатель может обратиться к официальному документу Cisco IOS Security Configuration Guide за более подробной информацией, вместо этого перейдем к примеру на основе нашей сети. Для начала определим правило инспектирования myrule трафика с помощью CBAC:


!
ip inspect name myrule ftp
ip inspect name myrule http
ip inspect name myrule realaudio
ip inspect name myrule h323
ip inspect name myrule smtp
ip inspect name myrule tftp
ip inspect name myrule udp
ip inspect name myrule tcp

!

Затем применим правило myrule ко входящему трафику на внутренний интерфейс E0/1:

!

interface Ethernet0/1
description intranet

ip address 121.132.143.1 255.255.255.0

no ip directed-broadcast

no ip proxy-arp

ip inspect myrule in

ip access-group 101 in

no cdp enable

!


Список доступа с номером 111 на внешнем интерфейсе будет фильтровать прямые обращения извне во внутреннюю сеть. Именно в него CBAC будет вносить временные разрешающие записи:

!
interface Ethernet0/0

description extranet to ISP
ip address 213.241.12.5 255.255.255.252
no ip directed-broadcast

no ip proxy-arp

ip inspect myrule out

ip access-group 111 in
no cdp enable

Список доступа за номером 101 будет определять инспектируемый трафик. Вторым его назначением будет антиспуфинг и блокирование «неиспользуемых»/«неизвестных» протоколов:

!

access-list 101 permit tcp 121.132.143.0 0.0.0.255 any

access-list 101 permit udp 121.132.143.0 0.0.0.255 any

access-list 101 permit icmp 121.132.143.0 0.0.0.255 any

access-list 101 deny ip any any

!


А следующий список доступа, применяемый к внешнему интерфейсу будет блокировать все входящие запросы во внутреннюю сеть. Стоит отметить, что в случае использования некоторых протоколов динамической маршрутизации, в частности EIGRP, требуется разрешить их отдельно, так как их применение подразумевает наличие многоадресной рассылки, будьте аккуратны:

!
access-list 111 deny ip 121.132.143.0 0.0.0.255 any

access-list 111 permit igrp any any


Естественно, для того, чтобы иметь рабочие инструменты отладки, требуется разрешить использование некоторых типов пакетов ICMP:

access-list 111 permit icmp any 121.132.143.0 0.0.0.255 administratively-prohibited

access-list 111 permit icmp any 121.132.143.0 0.0.0.255 echo

access-list 111 permit icmp any 121.132.143.0 0.0.0.255 echo-reply

access-list 111 permit icmp any 121.132.143.0 0.0.0.255 packet-too-big

access-list 111 permit icmp any 121.132.143.0 0.0.0.255 time-exceeded

access-list 111 permit icmp any 121.132.143.0 0.0.0.255 traceroute


Ну и наконец финальным аккордом запрещаем все остальное:

access-list 111 deny ip any any

!


Пожалуй, если теперь свести все настройки из первой и второй части статьи, мы получим достаточно безопасную конфигурацию нашего маршрутизатора, обеспечивающего надлежащий уровень защиты пользователей и самого себя от различных видов атак. Конечно, полная безопасность это миф, и даже такая настройка не гарантирует лечение паранойи, ведь нет предела совершенству. А совершенствоваться необходимо постоянно и лучшим источником информации для этого, конечно, является официальная документация, обращайтесь к ней чаще, ведь множество не менее интересного, хотя и реже используемого функционала так и осталась за бортом этой статьи. Всего наилучшего.

Ссылки и источники:

Cisco IOS Security Configuration Guide
Building Bastion Routers Using Cisco IOS
http://www.faqs.org/rfcs/rfc1918.html
http://www.faqs.org/rfcs/rfc2365.html

Настраиваем неприступный маршрутизатор. Часть 1.

Статья была опубликована в журнале IT-Спец за март 2008 г.

Хотелось бы сразу сказать, что данная статья не претендует на какую-либо уникальность и новизну. Я лишь еще раз повторю то, что говорили уже много раз, однако постараюсь привнести в это сказанное некую изюминку. Проще говоря статья повествует о том, как защищает свои маршрутизаторы автор. Статья рассчитана на человека, который знаком с операционной системой IOS маршрутизаторов Cisco и имеет базовые представления о принципах коммутации, маршрутизации и сетевых протоколах. В основном я буду рассматривать IOS версии 12.4 с функционалом advansed IP services, однако с большой долей вероятности все нижесказанное может быть применено к более старым операционным системам.

0. О том, как надо защищаться.
Основным принципом защиты маршрутизатора является запрет всего, кроме того, что разрешено. Помимо этого хорошей идеей является запрет того функционала, который будет использоваться редко, не имеет смысла в использовании или назначение которого нам не совсем ясно. Конечно, последний пункт должен быть исключением, так как мы всегда можем ознакомиться с огромным набором документации.

И так, план действий защиты таков:
1.Настройка аутентификации и паролей
2.Ограничение доступа к маршрутизатору
3.Отключение лишних служб и включение дополнительных
4.Настройка SNMP
5.Настройка журналирования


1.Операционная система Cisco IOS во многом очень схожа с большинством операцион6ных систем семейства UNIX. Как и в *nix-системах все основные операции по настройке и работе с маршрутизатором происходят посредством взаимодействия с командной оболочкой (CLI). Доступ к командной оболочке можно получить через удаленный терминал (vty), консольный порт (con), либо через модем на порту aux. Чаще всего весь процесс взаимодействия с маршрутизатором происходит через удаленный терминал. Консольный порт применяется лишь в экстренных случаях или в случае острой паранойи. Если маршрутизатор установлен на чужой территории, например вы арендуете место в шкафу, то можно отключить консоль и аuх порты, чтобы предотвратить физический доступ к маршрутизатору. Однако вам тогда будет сложнее самим зайти на него в случае потери удаленного управления. Модем часто применяется как резервный канал доступа к маршрутизатору, но в последнее время его применяют все реже. Существуют два основных режима, в котором можно работать с командной оболочкой: непривилегированный режим (EXEC level) и привилегированный режим (privileged EXEC level). Привилегированный режим позволяет изменять настройки маршрутизатора в режиме конфигурации. По большому счету это очень напоминает непривилегированного пользователя и root. Примерно как обычный пользователь *nix системы использует команду su для авторизации исполнения команд с правами root, в IOS используется команда enable. Всего в IOS доступны 15 уровней приоритетов. Привилегированный режим обычно имеет уровень приоритета 15, в то время как обычный пользователь в непривилегированном режиме имеет уровень 1. Кроме того администратор может задать определенный набор команд, доступный для пользователя в соответствии с его режимом приоритета, например так:

!
enable secret level 4 5 $1$6Dr/$vVMNdSKUfSkF.o9IMasrt1
!
privilege exec level 4 traceroute
privilege exec level 4 ping
privilege exec level 4 clear
privilege exec level 4 show configuration
!

Пароли в конфигурации маршрутизатора могут быть нескольких типов:
- обычные открытые (plain-text) пароли
- type 7 пароли
- type 5 пароли
По-умолчанию в конфигурации маршрутизатора пароли хранятся в открытом тексте и любой, кто имеет доступ к привилегированному режиму командной оболочки или к самому файлу конфигурации может увидеть их просматривая show running-config или show startup-config. Избежать этого можно с помощью кодирования паролей командой

service password-encryption

После применения этой команды все plain-text пароли в конфигурации заменяются на так называемые type 7 пароли, которые представляют из себя набор цифр и заглавных букв от A до F. Хотя формально эти пароли и зашифрованы, назвать шифрованием такой метод сложно так как основан он на применении XOR-подобной функции с ключом

dsfd;kfoA,.iyewrkldJKDHSUBsgvca69834ncxv9873254k;f g87

Существует множество утилит для расшифровки type 7 паролей, множество из которых доступно на packetstormsecurity.org и ему подобных сайтах. С таким же успехом пароль может быть раскодирован на самом маршрутизаторе с помощью нехитрой последовательности действий. Для начала включим режим шифрования plain-text паролей и добавим некого тестового пользователя с паролем «passw0rd»:

Router(config)#service password-encryption
Router(config)#username test password passw0rd
Теперь выполним команду show и выведем нашу строку:
Router(config)#do show run | include username
username test password 7 044B0A151C361C5C0D
Затем создадим цепочку ключей и введем type-7 пароль как ключевую строку для него:
Router(config)#key chain decrypt
Router(config-keychain)#key 0
Router(config-keychain-key)#key-string 7 044B0A151C361C5C0D
А теперь с помощью show выведем расшифрованную строку:
Router(config-keychain-key)#do show key chain decrypt
Key-chain decrypt:
****key 1 -- text "passw0rd"
********accept lifetime (always valid) - (always valid) [valid now]
********send lifetime (always valid) - (always valid) [valid now]
Как видим, безопасность type 7 паролей оставляет желать лучшего. Выхода может быть два — один из них оригинальный и нестандартный, другой — соответственно полная его противоположность. В качестве последнего можно использовать type 5 (или так называемые secret) пароли, которые переставляют из себя md5-хеши. Как известно, при достаточной длине пароля взломщик встретится с трудно решаемой вычислительной задачей, чего, в принципе, должно быть достаточно для защиты. Примером type 5 может служить пароль на режим enable:
enable secret 5 $1$3ORt$Pf.hrk2RehgDs3w7L5ER/0

Брать в рассмотрение первый способ рекомендую только в крайнем случае (например, выраженное проявление паранойи). Заключается он в модификации бинарного образа операционной системы маршрутизатора и изменении вышеупомянутого ключа шифрования. Не вдаваясь в подробности, скажу лишь что образ IOS представляет собой запакованный в слегка модифицированный zip-архив бинарный ELF-файл, который очень похож на ядро Linux и других подобных операционных систем. Строка шифрования представлена в нем в открытом виде и для ее модификации можно воспользоваться любым шестнадцатеричным редактором. Единственную проблему может представлять специальное поле контрольной суммы образа, которое необходимо будет переписать после изменения ключа и перепаковки образа. Как для распаковки, так и для корректной упаковки с подсчетом контрольной суммы можно использовать утилиту ciscopack от создателей книги «Hacking Exposed Cisco Networks». Скачать ее можно здесь: http://www.hackingciscoexposed.com/t...scopack.tar.gz.
Пример использования:

usage: ./ciscopack.pl [--unpack=imagename ]

Options:
--upack Upack cisco IOS image
--pack Pack new imagename
--head Head (Self extractor) to pack
--body Body (IOS body) to pack
--readheader Read the file header
--help This message

Естественно, проводить эксперименты рекомендуется не на используемом в активном сетевом взаимодействии маршрутизаторе, так как последствия неправильной модификации могут быть катастрофическими. В своих исследованиях я использовал эмулятор dynamips для запуска образов операционной системы IOS платформы 3725 (c3725-adventerprisek9-mz.124-18.bin) и шестнадцатеричный редактор biew для модификации образа IOS.

ciscopack.pl --unpack c3725-adventerprisek9-mz.124-18.bin --head c3725-adventerprisek9-mz.124-18.bin.head
ciscopack.pl, , V 0.1
Unpacking image: c3725-adventerprisek9-mz.124-18.bin
Written 7078 byte to c3725-adventerprisek9-mz.124-18.bin.head
Magic is found, reading the archive info
Compressed size:81980888 byte. Compressed size:39184467 byte
Compressed checksum: 0xb1dff6e0 Uncompressed checksum: 0x26adfdf2
Written Kb38267 to c3725-adventerprisek9-mz.124-18.bin.zip
uzip c3725-adventerprisek9-mz.124-18.bin.zip
Archive: c3725-adventerprisek9-mz.124-18.bin.zip
inflating: C3725-AD.BIN
All done!

Полученный распакованный образ я модифицировал в шестнадцатеричном редакторе biew, заменив строку:

dsfd;kfoA,.iyewrkldJKDHSUBsgvca69834ncxv9873254k;f g87

на строку:

shados.oA,.iyewrkldJKDHSUBsgvca69834ncxv9873254k;f g87

После этого проведем тест. Загружаем модифицированный образ в эмулятор:

dynamips -P 3725 C3725-AD.bin


После загрузки, отменяем вход в режим начальной конфигурации, включим сервис шифрования паролей и создадим пользователя с паролем «notracable»:

Router(config)#service password-encryption
Router(config)#username shados password notcracable
Теперь выполним команду show и выведем нашу строку:
Router(config)#do show run | include username
username test password 7 04011C120c334d4d0218071B17


Полученную строку попытаемся расшифровать в хорошо известной утилите Cain&Able (www.oxid.it). Результат можно видеть на скриншоте. Как видим, исходный пароль и расшифрованный отличают — трюк сработал. Образ, загруженный в эмулятор оттестирован и готов к использованию на реальном маршрутизаторе после переупаковки:

./ciscopack.pl --pack c3725-adventerprisek9-mz.124-18.bin --head c3725-adventerprisek9-mz.124-18.bin.head —body С3725-AD.bin

Пожалуй, на этом с собственно паролями закончим и перейдем к авторизации. Естественно, для настройки авторизации будем использовать наиболее современные методы, такие как модульный фреймворк AAA (Authentication, Authorization, Accounting). Для настройки этого сервиса требуется выполнить всего несколько простых действий:

1.Включить использование AAA посредством команды глобальной конфигурации
aaa new-model
2. Если принято решение использовать внешний сервер безопасности, следует на стоить параметры работы его протокола (например, RADIUS, TACACS+, Kerberos)
3.Определить списки методов аутентификации
4.Применить созданный список для конкретного интерфейса или линии
5.Если требуется — настроить авторизацию и аккаунтинг.


В качестве примера настроим аутентификацию посредством TACACS+. Если по TACACS+ аутентифицироваться не удастся — переходим к локальной аутентификации:

Router(config)#aaa new-model
Router(config)#aaa authentication login default group tacacs+ local-case
Router(config)#aaa authentication enable default group tacacs+ enable
Router(config)#aaa authorization commands 15 default group tacacs+ local
Router(config)#aaa accounting exec default stop-only group tacacs+
Router(config)#aaa accounting commands 15 default stop-only group tacacs+
Router(config)#aaa accounting network default stop-only group tacacs+
Router(config)#tacacs-server host 172.16.1.100
Router(config)#tacacs-server key cisco


Так, например, если аутентифицироваться для удаленного входа в exec режим через TACACS+ сервер не удастся (сервер недоступен), мы попытаемся аутентифицироваться в локальной базе пользователей:

username secret

Логично, что для большей защищенности стоит использовать символы разных регистров — это значительно усложнит жизнь переборщикам паролей.
Помимо всего прочего хорошей идеей будет изменить стандартное приглашение ввода имени пользователя и пароля. Пусть, допустим, оно будет сходно приглашению Linux:

Router(config)#aaa authentication password-prompt "password: "
Router(config)#aaa authentication username-prompt "login as: "

Такой трюк как минимум запутает взломщика, привыкшего видеть стандартное приглашение маршрутизатора.

2. Перейдем ко второму пункту наших действий — ограничение удаленного доступа. Конечно, чаще всего на маршрутизатор оператору или сетевому администратору придется получать доступ через удаленный терминал. Отсюда следует простая мысль, что этот же путь попытается проследовать взломщик (лицо, осуществляющее несанкционированное вторжение; пожалуй, здесь я сделаю небольшое лирическое отступление и позволю себе заметить, что намеренно не ассоциирую взломщика с хакером по известным этическим причинам и соображениям). Общая схема такова — доступ к консоли ограничиваем таймаутом в 15 минут, доступ через порт AUX отключаем полностью, доступ к виртуальному терминалу ограничиваем стандартным списком доступа, в качестве транспорта используем протокол ssh и также ограничиваем сессию таймаутом в 15 минут. Стандартный список доступа разрешает доступ только с двух доверенных машин, все остальные запросы фильтруются. Будем использовать протокол SSH версии 2 ввиду его большей безопасности, ограничим таймаутом и включим его журналирование. Ниже привожу вырезку из конфигурации устройства:

!
ip ssh time-out 15
ip ssh logging events
ip ssh version 2
!
!
access-list 100 permit 172.16.1.100
access-list 100 permit 172.17.1.200
access-list 100 deny any
!
line con 0
exec-timeout 15 0
line aux 0
exec-timeout 0 0
no exec
transport input none
line vty 0 4
access-class 100 in
exec-timeout 15 0
transport input ssh
!

Позволю себе напомнить читателю, что для того, чтобы использовать протокол SSH необходимо задать домен маршрутизатора и имя хоста, а затем сгенерировать RSA ключи достаточной длинны (автор всегда выбирает максимально доступную длину, в частности 2048):

Router(config)#ip domain name something.ru
Router(config)#crypto key generate rsa

Интересен один момент — в фильтрации удаленного доступа тоже есть место для трюка. В документации по операционной системе IOS 12.4 нет упоминания о том, что помимо стандартных списков доступа можно использовать еще и именованные. Грех этим не воспользоваться в своих целях. Хорошим примером применения этого функционала можно считать разрешение доступа по протоколу telnet из внутренней сети технических специалистов, а доступ с внешних адресов разрешить по протоколу ssh. Кроме этого, именованные списки доступа позволяют вести журналирование запросов. Ниже приведу пример, из которого станет все понятно:

!
ip access-list extended TerminalAccess
permit tcp 172.16.1.0 0.0.0.255 any eq telnet log
permit tcp any any eq 22 log
deny tcp any any log
!
line vty 0 4
access-class TerminalAccess in
transport input telnet ssh

Завершающим аккордом второго этапа будет настройка задержки между повторными вводами учетныйх данных:

Router(config)#login delay 5
Router(config)#login block-for 60 attempts 3 within 30

Первой командой мы устанавливаем задержку между повторными вводами равной пяти секундам. Второй командой устанавливаем блокировку на 60 секунд в случае трех неудачных попыток ввода имени пользователя/пароля в течение 30 секунд.

3. Третий этап наших действий по защите состоит в отключении всех ненужных и небезопасных служб маршрутизатора. На мой взгляд этот этап является наиболее простым и наименее творческим.
Командой глобальной конфигурации отключаем использование протокола CDP (Cisco Discovery Protocol). Это защитит наш маршрутизатор от раскрытия критичных данных о платформе, версии и т.п.

Router(config)#no cdp running

Проверим, отключены ли простые службы, аналогичные службам inetd типа chargen:

Router(config)#no service tcp-small-servers
Router(config)#no service udp-small-servers

Включим службы keep-alive, чтобы защититься от возможного перехвата, например, сессии telnet:

Router(config)#service tcp-keepalives-in
Router(config)#service tcp-keepalives-out

Отключим доспуп к маршрутизатору по протоколам http и https, так как все основные задачи по конфигурированию маршрутизатора будем выполнять через командную оболочку:

Router(config)#no ip http server
Router(config)#no ip http secure-server

Если не планируется использовать протокол динамического присвоения IP-адресов, отключим его:

Router(config)#no service dhcp

Маршрутизацию от источника, резолвинг DNS-имен, finger и тому подобные службы, необходимость которых сомнительна, либо если служба является потенциально небезопасной также отключаем:

Router(config)#no ip source-route
Router(config)#no ip finger
Router(config)#no ip bootp server
Router(config)#no ip domain-lookup

Скорее всего для журналирования потребуется использовать централизованную синхронизацию времени с NTP- сервером (Network Time Protocol)*. Выставляем правильную временную зону, соответствующую нашему расположению, назначаем ключ аутентификации для сервера и, собственно, указываем сам сервер:

Router(config)#clock timezone GMT 3
Router(config)#ntp authenticate
Router(config)#ntp authentication-key 1 md5 <ключ>
Router(config)#ntp server 172.16.1.100

Завершающей частью этого пункта включим автоматическую проверку целостности образа операционной системы IOS, который может быть как поврежден во время передачи, так и модифицирован злонамеренно с целью внедрения рукткита:

Router(config)#file verify auto

Пример работы службы контроля целостности:

Verifying file integrity of flash:c2600-ipbasek9-mz.124-17.bin............................................ .................................................. ............................Done!
Embedded Hash MD5 : 5DB1422925E26D7AEAB3DB9AF919AF83
Computed Hash MD5 : 5DB1422925E26D7AEAB3DB9AF919AF83
CCO Hash MD5 : EB9561C52A02E1DECD8490ED2935B5E9

Signature Verified
Verified flash:c2600-ipbasek9-mz.124-17.bin

4. Атаки на SNMP, пожалуй, являются одними из опаснейших, поэтому защите SNMP-агента маршрутизатора следует уделить пристальное внимание. Основной вектор атак на SNMP в случае маршрутизатора Cisco под управлением операционной системы IOS является получение конфигурации через CISCO-CONFIG-COPY-MIB. Атака может быть успешно проведена только в случае наличия строки community, доступной на запись. Маршрутизаторы Cisco под управлением IOS 12.4 поддерживают 3 основных модели SNMP — v1, v2c и v3. Соответственно каждая из моделей обеспечивает свой уровень защищенности, однако выбор ее зависит, в основном, от используемой системы мониторинга, а точнее от ее совместимости с используемой моделью безопасности. Естественно, для наибольшей безопасности рекомендуется использовать наиболее совершенную модель SNMPv3, отличающуюся наличием аутентификации по MD5 и SHA-ключам, 56-ти битным шифрованием данных по алгоритму DES, а также разграничением политик доступа пользователей по группам. Приведу пример настройки:

Router(config)#snmp-server group netadmins v3 priv
Router(config)#snmp-server user operator netadmins v3 auth md5 AuthPassw0rd priv des56 EncryptionPassw0rd

Первой командой мы создаем группу «netadmins» и указываем, что каждый пакет необходимо аутентифицировать и шифровать. Следует заметить, что одна из самых распространенных систем мониторинга Cacti умеет работать только с группами, опция которых установлена в auth. Второй командой мы создаем пользователя «operator», входящего в группу «netadmins», и указываем что аутентифицироваться он будет по md5-паролю, а шифрование данных будет происходить по протоколу DES. Для проверки работоспособности воспользуемся утилитой snmpwalk, где 172.16.1.1 — ip-адрес маршрутизатора:

snmpwalk -v 3 -u operator -A AuthPassw0rd -x DES -X EncryptionPassw0rd -l AuthPriv 172.16.1.1

Для большей защищенности можно определить список доступа, ограничивающий доступ к внешним серверам tftp, ftp, sftp и т.д.:

!
access-list 100 permit 172.16.1.100
access-list 100 permit 172.17.1.200
access-list 100 deny any
!
snmp-server file-transfer access-group 100

На этом, пожалуй, настройку протокола SNMP закончим и перейдем к настройке журналирования.

Для начала определим, в каком формате будут записываться временные отметки в журнале. По умолчанию маршрутизатор заносит в журнал записи с временной отметкой uptime. Чтобы изменить это поведение на стандартный формат date/time, необходимо выполнить следующую настройку:

Router(config)#service timestamps debug datetime localtime
Router(config)#service timestamps log datetime localtime

Затем определим размер буфера для журнала и уровень важности событий (severity), которые будут заноситься в журнал и отключим вывод системных сообщений на консоль, чтобы не перегружать маршрутизатор:

Router(config)#logging buffered 8128 debugging
Router(config)#no logging console

Затем укажем в конфигурации, что нам требуется заносить в журнал события в случае если аутентификации пользователя была успешной или произошла ошибка ввода логина/пароля:

Router(config)#login on-failure log
Router(config)#login on-success log

Изменение уровня привелегий пользователя также будем журналирвать:

Router(config)#logging userinfo

Пример вывода сообщений журнала:
Router>enable
Password:
*Mar 1 10:41:18: %SYS-5-PRIV_AUTH_PASS: Privilege level set to 15 by admin on console
Router#disable
*Mar 1 10:41:19: %SYS-5-PRIV_AUTH_PASS: Privilege level set to 1 by admin on console


Неоспоримый интерес для выяснения причин возможных проблем в случае ошибочной настройки представляет ведение истории команд режима конфигурации:

!
archive
log config
logging enable
notify syslog
hidekeys
!

Пример вывода сообщений журнала:

*Mar 1 10:41:24: %PARSER-5-CFGLOG_LOGGEDCMD: User:admin logged command:!exec: enable
*Mar 1 10:44:32: %PARSER-5-CFGLOG_LOGGEDCMD: User:admin logged command:arp 172.16.1.110 abcd.1234.8765 arpa

И последним шагом настройки укажем syslog-сервер, на который будем отправлять сообщения. В качестве транспортного протокола для наибольшей надежности соединения и гарантии доставки сообщений будем использовать TCP. Естественно, syslog-сервер должен поддерживать работу по протоколу TCP. Примером может служить syslog-ng:

Router(config)#logging host 172.16.1.155 transport tcp port 514

Итак, подводя некоторые итоги мы выполнили часть работы по настройке самого маршрутизатора, настроив безопасную работу его служб, обеспечили журналирование важных системных событий, ограничили удаленный доступ к маршрутизатору и задали надежные пароли доступа. В следующей части статьи мы перейдем к настройке безопасного межсетевого взаимодействия, защите от DDoS-атак, предотвращению паразитного трафика, а также к защите от злонамеренного контента и вирусов, в общем говоря ко всему, что связанно с фильтрацией и файрволлингом трафика, проходящего через маршрутизатор.

Ссылки:

Cisco IOS Security Configuration Guide (www.cisco.com)
Configuring Secure Shell on Routers and Switches Running Cisco IOS (www.cisco.com)
Network Management System: Best Practices: White Paper (www.cisco.com)
Cisco IOS hints and tricks (ioshints.blogspot.com)
Cisco IOS from an Attacker's Point of View (www.hakin9.org)
Building Bastion Routers Using Cisco IOS (Phrack Magazine #55)
Укрощение дикой киски, или сливаем пароли чемоданами (журнал Xakep #109)