Необходимые знания по IPSec:
Проблемы безопасности в разрезе передачи информации через через ip сети:
Соответственно задачи srx при построении ipsec туннеля будут такими:
Шифрование - процесс перевода plaintext в нечитаемый вид, т.н. ciphetext.
Основные составными части шифрования - алгоритм и ключ шифрования, что бы можно было расшифровать данные нужно знать алгоритм и ключ.
Типы шифрования :
Обмен информацией осуществляется в три этапа:
Размер ключа обычно варьируется от 40 до 1024 бит. Такой способ хорошо подходит для шифрования больших объемов данных. Надо аккуратно относиться к передачи секретного ключа.
Симметричное шифрование используется при построении ipsec туннелей, с каждой стороны пишем pre-shared-key (??).
Схема обмена информацией следующая:
Размер ключа обычно выбирают от 512 до 2048 бит. Т.к. ключ длинный процесс шифрование идет медленнее.
Данные зашифрованы и отправлены, теперь на стороне получателя надо проверить, что эти данные по пути не были модифицированы. Для этого используют алгоритмы хэширования.
Перед отправкой данные пропускаются через алгоритм хэширования и на выходе получается некое значение хэша.
Это значение отправляется вместе с данными.
На принимающей стороне данные прогоняются через тот же алгоритм хэширования и полученное значение хэша сравнивается со значением которые насчитал отправитель. Если значения одинаковые значит все хорошо, если значения не совпадают, то пакет дропается.
К функции хэша применяются след. требования:
Примером такой функции является функция определения остатка от деления - остаток при делении 80 на 11 будет равняться 3 (80 делим на 11 целое число раз и получаем остаток - целое число раз будет равняться 7, 7*11=77, 80-77=3 ). Зная, что остаток равняется 3 мы не сможем точно узнать что на что делилось.
80mod11=3
13mod5=3
203mod10=3 и т.д.
13mod5=3 эта такая форма записи в англоязычной литературе, к нашему модулю “| |” отношение вроде не имеет.
На на практике вычисления функция вычисления остатка не применяется, т.к. невозможно обеспечить уникальность результата.
Наиболее распространенными функциями являются SHA1, SHA3 (secure hash algoritm) и MD5 (message digest).
Данные зашифрованы - никто их не прочитает. Хэш посчитан - о изменении передаваемых данных узнаем.
Осталось убедиться, что мы обмениваемся данными с правильным “собеседником”.
Для этого применяется механизм HMAC (Hashed MeassageAuthentication Code).
Принцип hmac:
Ключи используются при шифровании и аутентификации, ключами надо как-то безопасно обмениваться.
Обменяться ключами можно в ручном режиме или автоматически.
При ручном обмене обычно с обоих сторон ставят один ключи и его всегда используют, передать этот ключ можно, например. на флешке. Часто менять ключ сложно т.к. его каждый раз надо надежным способом доставить и настроить.
При автоматическом обмене флешку возить не надо, но надо как-то безопасным образом передавать ключи через интернет. Для этого используют протокол Diffie-Hellman с помощью которого две стороны получают общий секретный ключ который в дальнейшем используются при не (Перечитать!!) симметричном шифровании.
У протокола DH есть несколько групп определяющие длину числа, над которым производятся математические вычисления (combination of exponential and modulus calculation), используемое при генерации ключа.
Junos поддерживает группы 1 (длина числа 768 бит), 2 (1024 бит) и 5 (1536 бит).
Вставить картинку с chapter7-7
—-
IPSec - это набор стандартов\протоколов с помощью которых можно организовать безопасную передачу данных через ip сети.
Два основных этапа:
IKE это протокол используемый для безопасного согласования параметров туннеля.
IKE работает по udp/500 и udp/4500. System service должен быть включен на интерфейсе от имени которого строится туннель.
{primary:node0}[edit security zones security-zone untrust]
admin@srx650-master# show
...
reth0.261 {
host-inbound-traffic {
system-services {
ping;
traceroute;
ike;
}
}
}
Обмен информацией осуществляется парными сообщениями «запрос — ответ». Такие пары называются «обмен» («exchange»).
Обмен данными в IKE происходит в 2 фазы. В первой фазе устанавливается SA IKE. Во второй фазе SA IKE используется для согласования пары SA IPSec.
Security Associations - это набор согласованных параметров (см. выше), ключей и протоколов которыми будет шифроваться данные. Другими словами SA в принципе можно назвать соединением, после установления которого начинается безопасная передача данных.
SA уникальна и идентифицируется след. параметрами:
SA IKE - устанавливается во время первой фазы, SA двунаправленная
{primary:node0}[edit security zones security-zone untrust]
admin@srx650-master# run show security ike security-associations
node0:
--------------------------------------------------------------------------
Index State Initiator cookie Responder cookie Mode Remote Address
8191533 UP ef6b34533d577417 7c3c47e505cbae39 Main 10.11.5.5
{primary:node0}[edit security zones security-zone untrust]
admin@srx650-master# run show security ike security-associations index 8191533 detail
node0:
--------------------------------------------------------------------------
IKE peer 10.11.5.5, Index 8191533, Gateway Name: IKE-GW-MSK-01-PTP
Role: Initiator, State: UP
Initiator cookie: ef6b34533d577417, Responder cookie: 7c3c47e505cbae39
Exchange type: Main, Authentication method: Pre-shared-keys
Local: 10.11.5.4:500, Remote: 10.11.5.5:500
Lifetime: Expires in 42709 seconds
Peer ike-id: 10.11.5.5
Xauth assigned IP: 0.0.0.0
Algorithms:
Authentication : hmac-sha1-96
Encryption : aes256-cbc
Pseudo random function: hmac-sha1
Diffie-Hellman group : DH-group-5
Traffic statistics:
Input bytes : 811208
Output bytes : 809296
Input packets: 8773
Output packets: 8743
IPSec security associations: 15 created, 15 deleted
Phase 2 negotiations in progress: 1
Negotiation type: Quick mode, Role: Initiator, Message ID: 0
Local: 10.11.5.4:500, Remote: 10.11.5.5:500
Local identity: 10.11.5.4
Remote identity: 10.11.5.5
Flags: IKE SA is created
SA IPSEC - устанавливается во время второй фазы через ранее установленный SA IKE, SA однонаправленный, нужно две.
{primary:node0}[edit security zones security-zone untrust]
admin@srx650-master# run show security ipsec security-associations
node0:
--------------------------------------------------------------------------
Total active tunnels: 24
ID Algorithm SPI Life:sec/kb Mon lsys Port Gateway
<131075 ESP:aes-cbc-256/sha1 2c00e182 2074/ unlim - root 500 10.11.5.5
>131075 ESP:aes-cbc-256/sha1 34ea8f60 2074/ unlim - root 500 10.11.5.5
{primary:node0}[edit security zones security-zone untrust]
admin@srx650-master# run show security ipsec security-associations detail index 131075
node0:
--------------------------------------------------------------------------
ID: 131075 Virtual-system: root, VPN Name: IKE-VPN-MSK-01-PTP
Local Gateway: 10.11.5.4, Remote Gateway: 10.11.5.5
Local Identity: ipv4_subnet(any:0,[0..7]=0.0.0.0/0)
Remote Identity: ipv4_subnet(any:0,[0..7]=0.0.0.0/0)
Version: IKEv1
DF-bit: clear, Bind-interface: st0.905
Port: 500, Nego#: 1644, Fail#: 0, Def-Del#: 0 Flag: 0x600a29
Tunnel events:
Tue May 30 2017 11:35:04 +0300: IPSec SA negotiation successfully completed (218 times)
Mon May 29 2017 23:38:32 +0300: IKE SA negotiation successfully completed (57 times)
Mon May 22 2017 23:38:01 +0300: Reached maximum allowed negotiation trigger. Delayed triggering negotiation (2 times)
Mon May 22 2017 23:15:42 +0300: IPSec SA negotiation successfully completed (48 times)
Sun May 21 2017 07:33:52 +0300: Reached maximum allowed negotiation trigger. Delayed triggering negotiation (1 times)
Sun May 21 2017 07:33:47 +0300: IPSec SA negotiation successfully completed (17 times)
Sat May 20 2017 17:30:06 +0300: Reached maximum allowed negotiation trigger. Delayed triggering negotiation (1 times)
Sat May 20 2017 17:30:01 +0300: IPSec SA negotiation successfully completed (3 times)
Sat May 20 2017 15:00:49 +0300: Reached maximum allowed negotiation trigger. Delayed triggering negotiation (1 times)
Mon Apr 03 2017 23:35:26 +0300: No response from peer. Negotiation failed (64 times)
Mon Apr 03 2017 19:40:34 +0300: IKE SA negotiation successfully completed (1 times)
Direction: inbound, SPI: 2c00e182, AUX-SPI: 0
Hard lifetime: Expires in 2056 seconds
Lifesize Remaining: Unlimited
Soft lifetime: Expires in 1494 seconds
Mode: Tunnel(0 0), Type: dynamic, State: installed
Protocol: ESP, Authentication: hmac-sha1-96, Encryption: aes-cbc (256 bits)
Anti-replay service: counter-based enabled, Replay window size: 64
Direction: outbound, SPI: 34ea8f60, AUX-SPI: 0
Hard lifetime: Expires in 2056 seconds
Lifesize Remaining: Unlimited
Soft lifetime: Expires in 1494 seconds
Mode: Tunnel(0 0), Type: dynamic, State: installed
Protocol: ESP, Authentication: hmac-sha1-96, Encryption: aes-cbc (256 bits)
Anti-replay service: counter-based enabled, Replay window size: 64
Тезисно:
В ходе первой фазы согласовываются следующие параметры:
Main mode Вставить картинку с chapter7-10
Message1 и Message2 - пиры обмениваются куками и SA пропосалами.
Куки это уникальные числа сгенеренные (был взят хэш) на основе ip адресов, порта, времени. Посмотреть на ответную куку инициатор соединения сможет убедиться, что ему ответил нужный пир.
SA пропосал это предложение по параметрам SA.
{primary:node0}[edit security ike]
admin@srx650-master# show proposal DEFAULT-FILIALS-IKE-PROPOSAL
authentication-method pre-shared-keys;
dh-group group5;
authentication-algorithm sha1;
encryption-algorithm aes-256-cbc;
lifetime-seconds 86400;
Message3 и Message4 - алгоритм DH обменялся публичными данными и сформировал симметричный ключ. Дальнейший обмен уже шифруется.
Message5 и Message6 - пиры аутентифицируют друг друга выбранным методом (preshared key, open key, digital signature) и фаза1 успешно завершается.
Aggresive mode Используется когда один из пиров имеет динамический ip адрес или стоит за натом т.к. в main mode первые два сообщения используют внешние адреса при формировании куков. Пир с динамическим адресом достоверное не знает его.
Вставить картинку с chapter7-11
Message1 - пир с динамическим адресом посылает куки, SA пропосал, публичные ключ алгорима DH.
Message2 - пир со статическим адресом посылает ответные куки, сообщение о принятии SA пропосал, свою публичное ключ алгорима DH. Дальнейший обмен уже шифруется.
Message3 - пир с динамическим адресом посылает один из ключей (preshared key, open key, digital signature) и если все хорошо, то второй пир аутентифицирует первого и фаза 1 успешно завершается.
Вставить картинку с chapter7-12
Message1 и Message2 - пиры обмениваются и согласовывают SA пропосалами.
SA пропосал включает в себя:
{primary:node0}[edit security ipsec]
admin@srx650-master# set proposal DEFAULT-FILIALS-IPSEC-PROPOSAL ?
Possible completions:
<[Enter]> Execute this command
+ apply-groups Groups from which to inherit configuration data
+ apply-groups-except Don't inherit configuration data from these groups
authentication-algorithm Define authentication algorithm
description Text description of IPSec proposal
encryption-algorithm Define encryption algorithm
lifetime-kilobytes Lifetime, in kilobytes (64..4294967294 kilobytes)
lifetime-seconds Lifetime, in seconds (180..86400 seconds)
protocol Define an IPSec protocol for the proposal
| Pipe through a command
{primary:node0}[edit security ipsec]
admin@srx650-master# show
...
proposal DEFAULT-FILIALS-IPSEC-PROPOSAL {
protocol esp;
authentication-algorithm hmac-sha1-96;
encryption-algorithm aes-256-cbc;
lifetime-seconds 3600;
}
...
policy DEFAULT-FILIALS-VPN-POLICY {
perfect-forward-secrecy {
keys group5;
}
proposals DEFAULT-FILIALS-IPSEC-PROPOSAL;
}
Message3 - принимаем пропосал, поднимаем пару SA IPSEC и успешно завершаем вторую фазу.
IPSec может работать в двух режимах:
—-
admin@srx650-master> show configuration security ike
...
proposal DEFAULT-FILIALS-IKE-PROPOSAL {
authentication-method pre-shared-keys;
dh-group group5;
authentication-algorithm sha1;
encryption-algorithm aes-256-cbc;
lifetime-seconds 86400;
}
...
policy IKE-POLICY-MSK-01 {
mode main;
proposals DEFAULT-FILIALS-IKE-PROPOSAL;
pre-shared-key ascii-text "$9$ixxxxxxxxxxxxxxxxxxxxxxxxxxxx6At"; ## SECRET-DATA
}
policy IKE-POLICY-MSK-01-PTP {
mode main;
proposals DEFAULT-FILIALS-IKE-PROPOSAL;
pre-shared-key ascii-text "$9$kxxxxxxxxxxxxxxxxxxxfz"; ## SECRET-DATA
}
...
gateway IKE-GW-MSK-01 {
ike-policy IKE-POLICY-MSK-01;
address 147.45.yyy.xxx;
dead-peer-detection always-send;
external-interface reth0.261;
}
gateway IKE-GW-MSK-01-PTP {
ike-policy IKE-POLICY-MSK-01-PTP;
address 10.11.5.5;
dead-peer-detection always-send;
external-interface reth0.162;
}
...
{primary:node0}
admin@srx650-master> show configuration security ipsec
...
proposal DEFAULT-FILIALS-IPSEC-PROPOSAL {
protocol esp;
authentication-algorithm hmac-sha1-96;
encryption-algorithm aes-256-cbc;
lifetime-seconds 3600;
}
...
policy DEFAULT-FILIALS-VPN-POLICY {
perfect-forward-secrecy {
keys group5;
}
proposals DEFAULT-FILIALS-IPSEC-PROPOSAL;
}
...
vpn IKE-VPN-MSK-01 {
bind-interface st0.5;
ike {
gateway IKE-GW-MSK-01;
ipsec-policy DEFAULT-FILIALS-VPN-POLICY;
}
establish-tunnels immediately;
}
vpn IKE-VPN-MSK-01-PTP {
bind-interface st0.905;
ike {
gateway IKE-GW-MSK-01-PTP;
ipsec-policy DEFAULT-FILIALS-VPN-POLICY;
}
establish-tunnels immediately;
}
...
{primary:node0}
admin@srx650-master> show configuration interfaces st0
...
unit 5 {
description vpn_to_msk-01;
family inet {
address 10.11.5.13/30;
}
}
...
unit 905 {
description vpn_to_msk-01_ptp;
family inet {
address 10.11.5.9/30;
}
}
{primary:node0}
admin@srx650-master> show configuration security zones security-zone vpn
...
st0.5 {
host-inbound-traffic {
system-services {
ping;
traceroute;
}
protocols {
ospf;
}
}
}
st0.905 {
host-inbound-traffic {
system-services {
ping;
traceroute;
}
protocols {
ospf;
}
}
}
...
{primary:node0}
admin@srx650-master> show route
...
192.168.5.0/24 *[OSPF/10] 5d 00:33:01, metric 2
> via st0.905
...