Сигурният ipsec протокол за пренос на данни. Овладяване на VPN: Настройване на IPSec на Cisco

мрежа, защитен тунел (Фигура 5.9), през който се предават поверителни или чувствителни към манипулиране данни. Такъв тунел се създава с помощта на криптографски методи за защита на информацията.

Протоколът работи на мрежовия слой на OSI модела и съответно е "прозрачен" за приложенията. С други думи, приложения (като напр уеб сървър, браузър, СУБД и т.н.) не влияе върху това дали предадените данни са защитени от IPSec или не.

Операционните системи от фамилията Windows 2000 и по-нови имат вградена поддръжка за IPSec протокола. От гледна точка на многослойния модел на сигурност, този протокол е средство за защита на мрежовия слой.


Ориз. 5.9.

Архитектурата IPSec е отворена, което по-специално позволява използването на нови криптографски алгоритми и протоколи за защита на предаваните данни, например тези, съответстващи на националните стандарти. Това изисква комуникиращите страни да поддържат тези алгоритми и те ще бъдат стандартно регистрирани в описанието на параметрите на връзката.

Процесът на защитен трансфер на данни се ръководи от правилата за сигурност, приети в системата. Параметрите на създавания тунел се описват от информационна структура, наречена контекст на сигурността или асоциация за сигурност (от англ. Security Association, съкр. SA). Както беше отбелязано по-горе, IPSec е набор от протоколи и съставът на SA може да варира в зависимост от конкретния протокол. SA включва:

  • IP адрес на получателя;
  • индикация за протоколите за сигурност, използвани при пренос на данни;
  • ключовете, необходими за криптиране и генериране на имитация на вложка (ако е необходимо);
  • указание за метода на форматиране, който определя как се създават заглавките;
  • индекс на параметрите за сигурност (от английски Security Parameter Index, съкр. SPI) - идентификатор, който ви позволява да намерите желания SA.

Обикновено контекстът на сигурността е еднопосочен и се използват две SA за прехвърляне на данни през тунела в двете посоки. Всеки хост има своя собствена SA база, от която желаният елемент се избира или въз основа на SPI, или чрез IP адреса на получателя.

Двата протокола, които съставят IPSec са:

  1. заглавен протокол за удостоверяване- AH (от англ. Authentication Header), който осигурява проверки за целостта и удостоверяване на предаваните данни; най-новата версия на протокола е описана в RFC 4302 (предишен - RFC 1826, 2402);
  2. Encapsulating Data Protection Protocol (ESP) Капсулиране на полезен товар за сигурност) - осигурява поверителност и по избор може да осигури проверка на целостта и удостоверяване, описани в RFC 4303 (предишен - RFC 1827, 2406).

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

Транспортен режимориентирана към хост връзка. Когато използвате ESP в транспортен режим, само данните на IP пакета са защитени, заглавката не се засяга. Когато използвате AH, защитата обхваща данните и част от полетата на заглавката. Режимите на работа са описани по-подробно по-долу.

AH протокол

В IP версия .4 заглавката за удостоверяване се поставя след заглавката на IP. Представете си оригиналния IP пакет като комбинация от IP хедъра, хедъра на протокола от следващо ниво (обикновено TCP или UDP, на Фигура 5.10 той е обозначен като ULP - от английски Upper-Level Protocol) и данни.


Ориз. 5.10.

Помислете за формата на заглавката на ESP (Фигура 5.13). Започва с две 32-битови стойности - SPIИ SN. Тяхната роля е същата като в протокола AH - SPIидентифицира SA, използван за създаване на този тунел; SN- позволява ви да се предпазите от повторение на пакети. SNИ SPIне са криптирани.

Следващото поле съдържа криптираните данни. След тях - поле за заместител, което е необходимо, за да се изравни дължината на криптираните полета до стойност, кратна на размера на блока на алгоритъма за криптиране.


Ориз. 5.12.


Ориз. 5.13.

Заместителят е последван от полета, съдържащи дължината на заместителя и указание за протокола от по-високо ниво. Четирите изброени полета (данни, контейнер, дължина, следващ протокол) са шифровани.

Ако ESP се използва и за удостоверяване на данни, тогава пакетът завършва с поле с променлива дължина, съдържащо ICV. За разлика от AH, в ESP, при изчисляване на стойността на вмъкване, полетата на IP хедъра (ново - за тунелен режим, модифицирано старо - за транспорт) не се вземат предвид.

Когато протоколите AH и ESP се използват заедно, след IP хедъра идва AH, след него - ESP. В този случай ESP решава проблемите с осигуряването на поверителност, AH - осигуряване на целостта и удостоверяването на източника на връзка.

Нека разгледаме редица допълнителни въпроси, свързани с използването на IPSec. Да започнем с това откъде идва информацията за параметрите на връзката - SA. Създаването на SA база може да стане по различни начини. По-специално, може да се създаде администратор по сигурносттаръчно или формирани с помощта на специални протоколи - SKIP, ISAKMP (Internet Security Association и Key Management Protocol) и IKE (Internet Key Exchange).

IPSec и NAT

При свързване на мрежи от организации към Интернет често се използва механизмът за транслация на мрежови адреси - NAT (Network Address Translation). Това ви позволява да намалите броя на регистрираните IP адреси, използвани в дадена мрежа. Вътре в мрежата се използват нерегистрирани адреси (като правило от диапазони, специално разпределени за тази цел, например адреси като 192.168.x.x за мрежи от клас C). Ако пакет от такава мрежа бъде изпратен към Интернет, тогава рутерът, на чийто външен интерфейс е присвоен поне един регистриран ip адрес, променя ip заглавките мрежови пакети, заменяйки регистрирания адрес с частни адреси. Начинът на извършване на замяната се записва в специална таблица. При получаване на отговор, в съответствие с таблицата, се извършва обратна замяна и пакетът се препраща към вътрешната мрежа.

Помислете за пример за използване на NAT на фиг. 5.14. В този случай частните адреси 192.168.0.x се използват във вътрешната мрежа. От компютъра с адрес 192.168.0.2 осъществяват достъп до външната мрежа към компютъра с адрес 195.242.2.2. Нека това е връзка към уеб сървър (HTTP протокол, който използва TCP порт 80).

Когато пакет преминава през рутер, който извършва преобразуване на адреси, IP адресът на подателя (192.168.0.2) ще бъде заменен с адреса външен интерфейсрутер (195.201.82.146) и запис, подобен на показания в

IPsec (IP сигурност)- набор от протоколи за сигурно предаване на трафик през IP мрежа. Може би най-сложният и разклонен протоколен стек, поддържан от системата VPNKI.

Включва три основни протокола:

  • AH (Authentication Header) - управление на целостта на предаваните данни и удостоверяване
  • ESP (Encapsulating Security Payload) - криптиране на данни
  • ISAKMP (Асоциация за интернет сигурност и протокол за управление на ключове) - управление на установяване на връзка, взаимно удостоверяване от крайни възли един на друг и обмен на секретни ключове

Основни използвани портове и номера на протоколи

  • UDP протокол, порт 500 (IKE, управление на ключове)
  • Протокол UDP, порт 4500 (IPSEC NAT-Traversal режим)
  • ESP протокол, стойност 50 (за IPSEC)
  • Протокол AH, стойност 51 (за IPSEC)

Като цяло пакетът протоколи IPsec не е прост по отношение на употребата си, която е многостранна. Въпреки това, основната характеристика на цялото взаимодействие по този протокол е концепцията за SA (Security Association) - това е набор от параметри за това как страните ще продължат да използват определени свойства на протоколи от IPsec.

Заслужава да се споменат и двата основни режима на работа на IPsec – тунелен и транспортен. Грубо казано, в транспортен режим само полезният товар на IP пакет е криптиран, докато в тунелен режим всички данни са криптирани, включително IP заглавките.

Удостоверяване

Взаимодействието на два възела започва с установяването на SA. По-точно от две асоциации - за протокола AH и ESP и в едната и в другата посока. SA започва с удостоверяване и след това страните се договарят за параметрите на бъдещата сесия:

  • за протокола AH - използвания алгоритъм за удостоверяване, ключове, живот на ключа и други параметри,
  • за протокола ESP - алгоритми за криптиране и удостоверяване, ключове, параметри за инициализация, продължителност на живота на ключа и други параметри.

Тук страните се договарят за тунела или транспортния режим на IPsec.

До края на процеса трябва да имате инсталирани няколко SA, но ... малко повече за това как е в действителност.

Фаза 1 и Фаза 2

В IPsec всичко се случва на фази.

Във фаза 1 се установява SA от първата фаза. В първата фаза страните се договарят относно метода за идентификация, алгоритъма за криптиране, алгоритъма за хеширане и групата Diffie Hellman. Тази фаза може да се извърши чрез обмен на три некриптирани пакета (агресивен режим) или шест некриптирани пакета - стандартен режим. Ако всичко върви добре, тогава се създава фаза 1 SA, наречена IKE SA, и се извършва преходът към втората фаза.

Във фаза 2 страните се договарят за политика и се създават самите ключове. Тази фаза, за разлика от първата, е напълно криптирана и се случва само в случай на успешно завършване на първата фаза. Тъй като трафикът в тази фаза е напълно криптиран, става трудно за отстраняване на неизправности, но ако всичко върви добре, се създава фаза 2 SA, наречена IPSec SA. На този етап можем да кажем, че тунелът е установен.

Компресиране на данни

IPsec няма собствен механизъм за компресиране на данни, но можете да използвате механизма IPcomp, за да компресирате съдържанието на IP пакет, преди да бъде предаден на IPsec процеса. Някои IPsec демони поддържат активирането на този механизъм от конфигурационните файлове ipsec.conf (напр. пакет Strongswan)

Автоматична проверка на здравето на VPN връзката

В рамките на IPsec няма стандартен инструмент за проверка на изправността на връзката (като ping), така че работата на тунела може да бъде проверена чрез външни средства.

Прекъснете VPN връзката и сменете ключовете

Ключовете, договорени на две фази, трябва да работят за времето, определено от политиката. Това означава, че може да се наложи страните да преживеят процедурата за повторно ключване, в противен случай договорените SA ще се разпаднат. Както бе споменато по-горе, страните имат ключове като част от процеса Фаза 1 (IKE) и Фаза 2 (IPsec). Процедурите за смяната им са различни, както и таймерите, които отговарят за това. За да се избегне прекъсване на комуникацията по време на процеса на повторно ключване, страните първо съгласуват параметрите на новия SA и едва след тази успешна процедура унищожават стария SA.

В IPsec има няколко начина за смяна на ключове на всяка от фазите – със или без удостоверяване, но няма да се фокусираме много върху това. Просто има твърде много нюанси за тази процедура, които зависят от версиите на софтуера и съотношението на таймерите - за IKE и IPsec.

    Предварително споделен ключ: Два миещи демона се свързват един с друг, потвърждават, че са тези, за които се представят (използвайки частния ключ по подразбиране, който сте задали в /etc/racoon/psk.txt). След това демоните генерират нов частен ключ и го използват за криптиране на трафик през VPN. Те променят този ключ периодично, така че дори ако нападателят счупи един от ключовете (което теоретично е почти невъзможно), това няма да му даде твърде много - той е счупил ключа, който два демона вече са променили с друг. Предварително споделеният ключ не се използва за шифроване на трафик през VPN връзката, той е просто токен, който позволява на демоните на ключовете да се доверяват един на друг. Разрешенията за файла psk.txt трябва да са 0600 (т.е. запис и четене само за root).

    IPsec се състои от два протокола:

    Encapsulated Security Payload (ESP), който защитава IP пакетните данни от намеса на трета страна чрез криптиране на съдържанието чрез симетрично криптографски алгоритми(като Blowfish, 3DES, AES).

    Заглавка за удостоверяване (AH), която защитава заглавката на IP пакета от намеса и фалшифициране на трета страна чрез изчисляване на криптографска контролна сума и хеширане на полетата на заглавката на IP пакета със защитена функция за хеширане. Допълнителен хеш хедър се добавя към пакета, за да позволи удостоверяване на информацията за пакета.

ESP и AH могат да се използват заедно или поотделно, в зависимост от обстоятелствата.

esp и ah са ipsec пакети, генерирани от ядрото, след като хостовете, с помощта на racoon, съгласуват ключ, използвайки протокола isakmp (500/udp).

Режими на работа на IPsec (транспорт, тунел)

Има два режима на работа на IPsec: транспортен режим и тунелен режим (когато само рутерите работят в транспортен режим).

IPsec може да се използва или за директно криптиране на трафик между два хоста (транспортен режим); или за изграждане на "виртуални тунели" между две подмрежи, които могат да се използват за осигуряване на връзки между две корпоративни мрежи (тунелен режим). Тунелният режим обикновено се нарича виртуална частна мрежа (виртуална частна мрежа, какво е VPN).

IN транспортен режимсамо информационната част на IP пакета е криптирана (или подписана). Маршрутизирането не е засегнато, тъй като IP хедърът на пакета не е променен (не е криптиран). Транспортният режим обикновено се използва за установяване на връзка между хостовете. Може да се използва и между шлюзове за защита на тунели, организирани по някакъв друг начин (IP тунел, GRE тунели и др.).

IN тунелен режимЦелият IP пакет е криптиран. За да се предаде по мрежата, той се поставя в друг IP пакет. По същество това е защитен IP тунел. Тунелният режим може да се използва за свързване на отдалечени компютри към виртуална частна мрежа или за организиране на защитено предаване на данни по отворени комуникационни канали (например интернет) между шлюзове за свързване на различни части на виртуална частна мрежа. Тунелният режим капсулира целия оригинален IP пакет и добавя нов IP хедър.

Ако IPsec се използва заедно с GRE тунели, които капсулират оригиналния пакет и добавят нов IP хедър, логично е да се използва транспортрежим.

IPsec режимите не се изключват взаимно. На един и същи хост някои SA могат да използват транспортен режим, докато други могат да използват тунелен режим.

Асоциации за сигурност (SA). За да могат да извършват капсулиране/декапсулиране, страните, участващи в процеса на обмен, трябва да могат да съхраняват секретни ключове, алгоритми и IP адреси. Цялата тази информация се съхранява в асоциациите за сигурност (SA), SA от своя страна се съхраняват в базата данни на асоциациите за сигурност (SAD). Конфигурирането на асоциацията за сигурност ви позволява да зададете например вид транспорт | тунел | ro | in_trigger | цвекло- защитен режим на асоцииране. Съответно, той може да приеме една от стойностите, което означава транспорт, тунел, цвекло (Bound End-to-End Tunnel), оптимизация на маршрута (оптимизиране на маршрута) или режими in_trigger. (последните две се използват в контекста на мобилен ipv6).

Политика за сигурност (SP)- политика за сигурност, съхранявана в SPD (Security Policy Database). SA уточнява как IPsec трябва да защитава трафика, SPD на свой ред съхранява Допълнителна информациянеобходими за определяне кой трафик да бъде защитен и кога. SPD може да укаже едно от трите действия за пакет от данни: отхвърляне на пакета, не обработване на пакета чрез IPSec, обработка на пакета чрез IPSec. В последния случай SPD също така указва кой SA да се използва (приемайки, че вече е създаден подходящ SA, разбира се) или указва с какви параметри трябва да бъде създаден нов SA. SPD е много гъвкав механизъм за управление, който позволява много добро управлениеобработка на всеки пакет. Пакетите се класифицират по голям брой полета и SPD може да провери някои или всички полета, за да определи подходящото действие. Това може да доведе до това, че целият трафик между две машини се изпраща с помощта на един SA или отделни SA се използват за всяко приложение или дори за всяка TCP връзка.

IPSec (net-to-net) между FreeBSD сървъри

    Етап 1: Създайте и тествайте "виртуална" мрежова връзка.

    • Настройте двете ядра с gif на устройството. Във FreeBSD поддръжката на gif е включена в ядрото.

      Редактирайте /etc/rc.conf на рутерите и добавете следните редове (замествайки IP адресите, където е необходимо). A.B.C.D е реалният IP на първия рутер, W.X.Y.Z е реалният IP на втория рутер. # IPsec #1 шлюз > ee /etc/rc.conf ... # IPsec към S през ISP_V gif_interfaces="gif0" # gifconfig_gif0="local-ip(A.B.C.D) remote-ip (W.X.Y.Z)" gifconfig_gif0="194.x.x.x 91.x.x.x" ifconfig_gif0="inet 10.26.95.254 192.168.1.254 netmask 255.255.255.255" static_routes="vpn vpn1" route_vpn="-net 192.168.1.0/24 192.168.1.254" route_vpn1="-net 192.168.35.0/24 192.168 .1.254" # IPsec #2 шлюз > ee /etc/rc.conf ... # IPsec na G през ISPGate gif_interfaces="gif0" # gifconfig_gif0="W.X.Y.Z A.B.C.D" gifconfig_gif0="91.x.x.x 194.x.x.x" ifconfig_gif0=" inet 192.168.1.254 10.26.95.254 мрежова маска 255.255.255.255" static_routes="vpn" route_vpn="-net 10.26.95.0/24 10.26.95.254"

      Редактирайте скрипта на защитната стена и на двата рутера и добавете # IPFW ipfw добавете 1 разреши ip от всеки към който и да е чрез gif0 # PF set skip on gif0

Сега ping трябва да преминава между мрежите.

    Защита на връзка с IPsec

    Стъпка 2: Сигурна връзка с IPsec

    • Конфигурирайте и двете ядра: > sysctl -a | grep ipsec

      ако командата не изведе нищо, тогава трябва да изградите отново ядрата на двата рутера с параметрите

      # IPSEC за FreeBSD 7.0 и по-нови опции IPSEC опции IPSEC_FILTERTUNNEL устройство крипто # IPSEC за FreeBSD 6.3 опции IPSEC # IP опции за сигурност IPSEC_ESP # IP сигурност (крипто; дефиниране с IPSEC) опции IPSEC_DEBUG # По избор. отстраняване на грешки за IP сигурност

      Задайте порта на ipsec-tools. > cd /usr/ports/security/ipsec-tools > make config > make install clean > ee /etc/rc.conf racoon_enable="ДА" ipsec_enable="ДА" > mkdir -p /usr/local/etc/racoon/ cert > cp /usr/local/share/examples/ipsec-tools/racoon.conf /usr/local/etc/racoon/racoon.conf > cd /usr/local/etc/racoon/cert/

      Ние създаваме SSL сертификатина всеки хост. Копираме файлове *.public от един в друг. По принцип имената на ключовете са маловажни, можете да ги извикате и по IP, със съответните разширения.

      > openssl req -new -nodes -newkey rsa:1024 -sha1 -keyform PEM -keyout your.key1.private -outform PEM -out your.key1.pem > openssl x509 -req -in your.key1.pem -signkey your. key.private -out your.key1.public

    Създаваме файла ipsec.conf. Настройка на шлюз #1 (където е публичният IP адрес на A.B.C.D) за активиране на криптиране на целия трафик, насочен към W.X.Y.Z. A.B.C.D/32 и W.X.Y.Z/32 са IP адреси и мрежови маски, които определят мрежите или хостовете, към които тази политика. В този случай искаме да ги приложим към трафика между тези два хоста. Опцията ipencap казва на ядрото, че тази политика трябва да се прилага само за пакети, които капсулират други пакети. Опцията -P out казва, че тази политика се прилага за изходящите пакети, а ipsec, че пакетите ще бъдат криптирани.

Останалата част от реда определя как тези пакети ще бъдат криптирани. Ще се използва протоколът esp, а параметърът на тунела показва, че пакетът ще бъде капсулиран в IPsec пакет по-късно. Повторното използване на A.B.C.D и W.X.Y.Z е да изберете кои опции за сигурност да използвате и накрая опцията за изискване позволява криптиране на пакети, които попадат в това правило.

Това правило съвпада само с изходящи пакети. Ще ви трябва подобно правило, за да съпоставите входящите пакети.

> ee /etc/ipsec.conf spdadd A.B.C.D/32 W.X.Y.Z/32 ipencap -P out ipsec esp/тунел/A.B.C.D-W.X.Y.Z/require; spdadd W.X.Y.Z/32 A.B.C.D/32 ipencap -P в ipsec esp/тунел/W.X.Y.Z-A.B.C.D/изискване;

Настройката на шлюз #2 е подобна, само че IP адресите са обърнати.

Настройване на помощната програма racoon

> ee пътят /usr/local/etc/racoon/racoon.conf включва "/usr/local/etc/racoon"; сертификат за път "/usr/local/etc/racoon/cert/"; # следващият ред активира регистрирането и трябва да се деактивира по-късно log debug; # ако не е дадена директива за слушане, racoon слуша всички налични # интерфейсни адреси. слушай ( #isakmp::1 ; isakmp 202.249.11.124 ; #admin ; # административен порт за racoonctl. #strict_address; # изисква всички адреси да бъдат обвързани. ) # описва отдалечения хост (на втората машина - идентичен, # текущ друг IP и ключове) отдалечен 217.15.62.200 ( exchange_mode aggressive,main; my_identifier asn1dn; peers_identifier asn1dn; # сертификати на тази машина тип сертификат x509 "via.epia.public" "via.epia.private"; # сертификат на отдалечената машина peers_certfile x509 "test.su .public"; предложение ( encryption_algorithm 3des; hash_algorithm sha1; authentication_method rsasig; dh_group 2 ; ) ) sainfo anonymous ( pfs_group 2; encryption_algorithm 3des; authentication_algorithm hmac_sha1; compression_algorithm deflate; )

    Настройка на PF филтъра за пакети, където esp_peers е шлюзът, с който се създава криптираният тунел. Разрешаваме преминаването на ESP и IPENCAP пакети и в двете посоки.

#pass IPSec pass in on $ext_if_a inet proto udp from ( $esp_peers ) to ($ext_if_a) port isakmp pass in on $ext_if_a inet proto esp from ( $esp_peers ) to ($ext_if_a) # pass in on $ext_if_a inet proto udp от ( $esp_peers ) до ($ext_if_a) порт isakmp предаване на $ext_if_a inet proto esp от ( $esp_peers ) до ($ext_if_a)

Разглеждаме регистрационните файлове /var/log/security и /var/log/messages.

След като опциите за защита са зададени, можете да ги видите с помощта на setkey(8). Бягай

> /etc/rc.d/ipsec start > /usr/local/etc/rc.d/racoon start > setkey -D # списък на създадените защитени канали > setkey -DP # показване на списък с политики за сигурност

на всеки от хостовете, за да видите информация за настройките за сигурност.

    Преглед на здравето:

    ping между мрежите трябва да работи

    Започваме да слушаме физическия интерфейс, върху който е изграден тунелът (а не виртуалния gif0). В друг прозорец, например, ping отдалечена сива мрежа (например ping 192.168.1.11) tcpdump -i em0 -n хост 91 .x.x.81 ... 16:15:54.419117 IP x.x.x.x >

tcpdump Примерите за използване на Linux трябва да показват ESP пакети.

IPSec (site-to-site) между Linux сървъри

# aptitude инсталирайте ipsec-tools racoon

    Алгоритъм за конфигуриране на IPsec

    Настройване на пакета racoon

    Създайте политика за сигурност

    виртуални интерфейси. Те са необходими за маршрутизиране на мрежи, разположени в локални мрежи. Два свързани сървъра ще се видят без интерфейси (понякога няма да стартира без тях между сървърите, всъщност е странно).

По-долу са конфигурациите за случая с предварително дефинирани ключове.

> пътят на nano /etc/racoon/racoon.conf включва "/etc/racoon"; път pre_shared_key "/etc/racoon/psk.txt"; #path сертификат "/etc/racoon/certs"; отдалечен 10.5.21.23 ( exchange_mode aggressive,main; doi ipsec_doi; ситуация identity_only; my_identifier адрес; #Дефинира метода за идентификация, който да се използва при удостоверяване на възли. продължителност на живота 2 минути; първоначален_контакт на; предложение (encryption_algorithm 3des; hash_algorithm sha1; authentication_method pre_shared_key; # Указва метода за удостоверяване, използван при договаряне на възли dh_group 2;) offer_check strict;) sainfo anonymous # Показва, че SA може автоматично да инициализира връзка към всеки партньор, когато IPsec идентификационните данни съвпадат. ( pfs_group 2; продължителност на живота 2 минути; encryption_algorithm 3des, blowfish 448, des, rijndael; authentication_algorithm hmac_sha1, hmac_md5; compression_algorithm deflate;)

Нека създадем политика за сигурност

> nano pol.cfg #!/sbin/setkey -f промиване; spdflush; spdadd 10.5.21.24 10.5.21.23 произволен -P out ipsec esp/transport//require; spdadd 10.5.21.23 10.5.21.24 произволен -P в ipsec esp/transport//require; > chmod +x pol.cfg > ./pol.cfg

Нека създадем изпълним файл за създаване на интерфейси и да го стартираме.

>nano tun.sh #!/bin/sh ip tunnel del tun0 ip tunnel add tun0 mode ipip remote 10.5.21.23 local 10.5.21.24 dev eth0 # създаване на интерфейс tun0 и установяване на тунел # между хостове (тук трябва да използвате реални IP адреси мрежови интерфейси). ifconfig tun0 10.0.9.1 pointopoint 10.0.9.2 # присвояване на IP адреси към интерфейса, за текущия хост и за другия # край на тунела (по избор). ifconfig tun0 mtu 1472 ifconfig tun0 up # по-долу можете да посочите маршрутите, от които се нуждаем, например route add -net ... netmask 255.255.255.0 gw ... route add -net ... netmask 255.255.255.0 gw ... > ./ tun.sh

За автоматично изтеглянеправила, файлът tun.sh трябва да бъде правилно поставен за Debian в директорията /etc/network/if-up.d

Всички IPSec тунели между мрежите са конфигурирани.

iptables IPSec

$IPT -A INPUT -p udp -m udp -s xxx.xxx.xxx.xxx -d xxx.xxx.xxx.xx --dport 500 -j ПРИЕМАНЕ $IPT -A INPUT -p esp -j ПРИЕМАНЕ $IPT - A INPUT -p ah -j ACCEPT $IPT -A INPUT -p ipencap -j ACCEPT $IPT -A INPUT -p udp -m udp -s xxx.xxx.xxx.xxx -d xxx.xxx.xxx.xx -- dport 4500 -j ПРИЕМАНЕ

IPsec хост към хост без виртуални интерфейси

Задача. Използвайте IPSec (pre_shared_key), за да свържете два сървъра (Debian 5 и Debian 7). И двете имат реално IP. Не е необходимо да се препращат мрежи. Трафикът между тези IP адреси трябва да бъде криптиран. Тоест изграждаме транспортен режим (между два хоста).

Настройката се свежда до две точки

    Настройване на пакета racoon

    Създаване на политика за сигурност: трябва да посочите транспортен режим и всеки spdadd x.x.x.x/32 y.y.y.y/32 всеки -P out ipsec esp/transport//require; spdadd y.y.y.y/32 x.x.x.x/32 произволен -P в ipsec esp/transport//require;

IPSec (GRE) (хост към мрежа) между Debian и Cisco

Задача:изграждане на IPsec в тунелен режим. Протокол RFC Описание SIP сигнализирането между доставчика (Cisco) и клиента (Debian 5) е криптирано с IPsec, а RTP заобикаля тунела по най-краткия маршрут през обикновения интернет.

    Крайната точка на клиентския тунел е: 193.xxx.xxx.xxx

    Крайната точка на сървърния тунел е: 62.xxx.xxx.xxx

    Клиентът на Sip Server е: 193.xxx.xxx.xxx

    SIP сървърите са: 62.xxx.237.xxx/26 и 62.xxx.246.xxx/26

и преди да настроите тунела (преди auto tun0), pre-up modprobe ip_gre

# modprobe ip_gre

Скрипт за създаване на GRE тунели в Debian:

#!/bin/sh -e modprobe ip_gre #ip tunnel del tun0 ip tunnel add tun0 mode gre remote 62.xxx.xxx.xxx local 193.xxx.xxx.xxx dev eth0 ifconfig tun0 mtu 1472 ifconfig tun0 up route add -net 62.xxx.237.xxx мрежова маска 255.255.255.192 dev tun0 route add -net 62.xxx.246.xxx мрежова маска 255.255.255.192 dev tun0

Помощни програми

    За контрол можете да използвате помощната програма racoonctl racoonctl show-sa esp

    Списък на създадените защитени канали > setkey -D

    списък с политики за сигурност > setkey -DP

IPsec мониторинг

Наблюдение на IPsec в Debian 5.0 2.6.26-2-686-bigmem i686. Нивото на подробност на уведомяването или отстраняването на грешки в журнала се задава във файла racoon.conf.

# опашка -F /var/log/syslog | grep racoon

IPSec Openswan

OpenSWAN започна да се разработва като разклонение на вече несъществуващия проект FreeS/WAN (Free Secure Wide-Area Networking), изданията продължават да се пускат под безплатния GNU General Public License. За разлика от проекта FreeS/WAN, OpenSWAN не е разработен само специално за операционната система GNU/Linux. OpenSWAN предоставя протоколния стек IpSec: AH и ESP за ядрото на Linux и инструментите за тяхното управление.

OpenSWAN за клона на ядрото 2.6 предоставя вградена NETKEY реализация на IpSec, както и собствен KLIPS.

CentOS 6.6 поддържа Openswan само в основни пакети.

Задача. Създайте криптиран тунел между CentOS 6.6 и Debian 7.8 Wheezy. GRE тунели + Openswan (тип=транспорт)

    Openswan ще криптира нашия трафик в транспортен режим (хост-хост), без да се намесва в маршрутизирането. Инсталирайте пакети и на двата сървъра yum инсталирайте openswan aptitude инсталирайте openswan

    В двата края на тунела задайте правила за iptables. Отворете порт 500 за обмен на сертификати и ключове. iptables -A INPUT -p udp --dport 500 -j ПРИЕМА iptables -A INPUT -p tcp --dport 4500 -j ПРИЕМА iptables -A INPUT -p udp --dport 4500 -j ПРИЕМА # По-стриктно напишете правилата за IPSec IPT ="/sbin/iptables" $IPT -A INPUT -p udp -s x.x.x.x -d x.x.x.x --dport 500 -m коментар - коментар"IpSec" -j ПРИЕМАНЕ $IPT -A ВХОД -p tcp -s x.x.x.x -d x.x.x.x --dport 4500 -m коментар --коментар "IpSec" -j ПРИЕМАНЕ $IPT -A ВХОД -p udp -s x.x.x.x -d x.x.x.x --dport 4500 -m коментар --comment "IpSec" -j ПРИЕМАНЕ

    Подготовка на конфигурационни файлове.Използвани файлове и директории / etc/ ipsec.d/ / etc/ ipsec.conf

    Проверка на системата за правилната среда за IPsec ipsec verify

    Добавете в края на файла sysctl.conf

    # IPSec Verify Compliant # Разрешаване на пренасочване на пакети между интерфейси за IPv4 net.ipv4.ip_forward = 1 # деактивиране на icmp пренасочване net.ipv4.conf.all.send_redirects = 0 net.ipv4.conf.all.accept_redirects = 0 net.ipv4.conf.default.send_redirects = 0 net.ipv4.conf.default.accept_redirects = 0

    Прилагане на опциите на ядрото без рестартиране

    Първият конфигурационен файл е /etc/ipsec.conf. Задайте изрично в раздела config setup config setup protostack =nekey plutoopts ="--perpeerlog" dumpdir =/ var/ run/ pluto/ nat_traversal =yes virtual_private =% v4:10.0.0.0/ 8 ,% v4:192.168.0.0/ 16 , % v4:172.16.0.0/ 12 ,% v4:25.0.0.0/ 8 ,% v6:fd00::/ 8 ,% v6:fe80::/ 10 oe =изключено #plutostderrlog=/dev/null

    На първо място, трябва да генерирате ключовете, използвани от шлюзовете за удостоверяване. В Debian този ключ може да бъде създаден по време на инсталацията. Изпълняваме ipsec newhostkey и на двете системи, генерирайки ключовете, от които се нуждаем. ipsec newhostkey --output / etc/ ipsec.secrets ipsec showhostkey --left ipsec showhostkey --right

    Независимо как конфигурирате сървъра, винаги мислете, че вашата подмрежа е от „ляво“ (вляво), а подмрежата, достъпвана от разстояние, сайтът, като „вдясно“ (вдясно). Следната конфигурация е направена на VPN сървъротляво. Другият сървър трябва да има точно същите настройкиза тази връзка. conn gagahost-to-miraxhost auto =start ляво =188 .x.x.x leftrsasigkey =0sN4vI6ooUyMyL ... дясно =91 .x.x.x rightrsasigkey =0sfAhuo4SQ0Qt ... type =transport scp / etc/ ipsec.conf [имейл защитен] 192.168.35.254:/начало/админ/

IPSec Openswan диагностика

Стартиране на услугата и отстраняване на проблеми.

Openwan трупи (плутон): /var/log/auth.log /var/log/syslog /var/log/pluto/peer/a/b/c/d/a.b.c.d.log

Ако няма грешки и на двата сървъра, тогава тунелът трябва да се издигне. Можете да тествате тунела с помощта на командата ping със следното. Ако тунелът не е отворен, тогава частната подмрежа от страна B не трябва да бъде достъпна от страна A, т.е. командата ping не трябва да работи. След като тунелът е готов, опитайте командата ping за достъп до частната подмрежа от страна B от страна A. Това трябва да работи.

В допълнение, маршрутите към частната подмрежа трябва да се показват в таблицата за маршрутизиране на сървъра.

# ip маршрут чрез dev eth0 src по подразбиране чрез dev eth0

    Команди за проверка на състоянието на връзката: ipsec verify service ipsec status ip xfrm state list - SAD управление, повече опции от setkey ipsec addconn --checkconfig - проверка на ipsec конфигурация auto --status - подробен статус ip xfrm monitor

    ipsec политики, които решават кой трафик да изпрати към тунела ip xfrm pol show

    tcpdump Примери за използване на Linux се изпълняват, за да надушат физическия интерфейс, върху който е изграден тунелът (не виртуалния GRE). В друг прозорец, например, пинг отдалечена сива мрежа (например пинг 192.168.1.11). tcpdump трябва да показва ESP пакети. tcpdump -i em0 -n хост 91 .x.x.81 ... 16 :15 :54.419117 IP x.x.x.x > 91 .x.x.81: ESP(spi =0x01540fdd,seq =0xa20) , дължина 92 ...

Връзки

В края на шейсетте години Американската агенция за напреднали изследвания в областта на отбраната (DARPA) реши да създаде експериментална мрежа, наречена ARPANet. През 70-те години ARPANet започва да се счита за действащата мрежа на САЩ и чрез тази мрежа е възможно да се получи достъп до водещите университети и научни центрове на САЩ. В началото на осемдесетте години започва стандартизацията на езиците за програмиране, а след това и на протоколите за мрежово взаимодействие. Резултатът от тази работа беше разработването на седемслоен модел на мрежово взаимодействие ISO / OSI и семейство протоколи TCP / IP, които станаха основа за изграждане както на локални, така и на глобални мрежи.

Основните механизми за обмен на информация в TCP/IP мрежите като цяло се формират в началото на осемдесетте години и са насочени основно към осигуряване на доставка на пакети данни между различни операционна системаизползване на разнородни комуникационни канали. Въпреки факта, че идеята за създаване на мрежата ARPANet (по-късно превърната в модерен интернет) принадлежеше на правителствена отбранителна организация, всъщност мрежата произхожда от изследователския свят и наследява традицията на откритост на академичната общност. Още преди комерсиализацията на Интернет (което се случи в средата на деветдесетте години), много уважавани изследователи отбелязаха проблемите, свързани със сигурността на протоколния стек TCP / IP. Основните концепции на протоколите TCP / IP не отговарят напълно (и в някои случаи противоречат) на съвременните представи за компютърна сигурност.

Доскоро Интернет се използваше главно за обработка на информация чрез сравнително прости протоколи: електронна поща, прехвърляне на файлове, отдалечен достъп. Днес, поради широкото използване на WWW технологиите, все повече се използват средствата за разпределена обработка на мултимедийна информация. В същото време нараства обемът на данните, обработвани в среда клиент/сървър и предназначени за едновременен споделен достъп от голям брой абонати. Разработени са няколко протокола на приложния слой, за да осигурят информационна сигурностприложения като имейл (PEM, PGP и др.), WWW (защитен HTTP, SSL и др.), управление на мрежата (SNMPv2 и др.). Въпреки това, наличието на инструменти за сигурност в основните протоколи на фамилията TCP / IP ще позволи обмен на информация между широк набор от различни приложения и услуги.

Кратка историческа справка за появата на протокола

През 1994 г. Internet Architecture Board (IAB) публикува доклада „Internet Architectural Security“. Този документ описва основните области на приложение на допълнителните инструменти за сигурност в Интернет, а именно защита срещу неоторизирано наблюдение, подправяне на пакети и контрол на потока от данни. Сред приоритетните и най-важни защитни мерки беше посочена необходимостта от разработване на концепция и основни механизми за осигуряване на целостта и поверителността на потоците от данни. Тъй като промяната в основните протоколи на семейството TCP / IP би довела до пълно преструктуриране на Интернет, задачата беше да се гарантира сигурността на обмена на информация в отворени телекомуникационни мрежи въз основа на съществуващи протоколи. Така започва да се създава спецификацията Secure IP, в допълнение към протоколите IPv4 и IPv6.

IPSec архитектура

IP Security е набор от протоколи, занимаващи се с криптиране, удостоверяване и сигурност при транспортирането на IP пакети; вече включва близо 20 предложения за стандарти и 18 RFC.

Спецификацията за IP сигурност (известна днес като IPsec) се разработва от работната група на IP Security Protocol на IETF. Първоначално IPsec включваше 3 независими от алгоритъма базови спецификации, публикувани като RFC „IP Security Architecture“, „Authentication Header (AH)“, „Encrypted Data Encapsulation (ESP)“ (RFC1825, 1826 и 1827). Трябва да се отбележи, че през ноември 1998 г. работната група по IP протокол за сигурност предложи нови версии на тези спецификации, които в момента имат статут на предварителни стандарти, това са RFC2401 - RFC2412. Имайте предвид, че RFC1825-27 се счита за остарял от няколко години и не се използва реално. Освен това има няколко зависещи от алгоритъма спецификации, които използват протоколите MD5, SHA, DES.

Ориз. 1 - IPSec архитектура.

Работната група за IP протокол за сигурност също разработва протоколи за управление на ключова информация. Задачата на тази група е да разработи Internet Key Management Protocol (IKMP), протокол за управление на ключове на приложния слой, който е независим от използваните протоколи за сигурност. Концепциите за управление на ключове в момента се разглеждат с помощта на спецификацията на асоциацията за интернет сигурност и протокола за управление на ключове (ISAKMP) и протокола за определяне на ключове на Oakley. Спецификацията ISAKMP описва механизмите за договаряне на атрибутите на използваните протоколи, докато протоколът Oakley ви позволява да задавате ключове за сесии на компютри в Интернет. По-рано бяха разгледани и възможностите за използване на механизми за управление на ключове SKIP, но сега такива възможности практически не се използват никъде. Стандартите за управление на ключова информация, които се създават, вероятно ще поддържат центрове за разпределение на ключове, подобни на тези, използвани в системата Kerberos. Протоколите за управление на ключове за IPSec, базирани на Kerberos, в момента се управляват от сравнително нов работна група KINK (Kerberized Internet Negotiation of Keys).

Гаранциите за целостта на данните и поверителността в IPsec спецификацията се осигуряват чрез използването съответно на механизми за удостоверяване и криптиране. Последните от своя страна се основават на предварителното споразумение на страните за така наречения обмен на информация. "контекст на сигурността" - използвани криптографски алгоритми, алгоритми за управление на ключова информация и техните параметри. Спецификацията IPsec предвижда възможност страните да обменят информация за поддръжка на различни протоколи и параметри за удостоверяване и криптиране на пакети данни, както и различни схеми за разпределение на ключове. В този случай резултатът от договарянето на контекста на сигурността е установяването на индекс на параметрите за сигурност (SPI), който е указател към определен елемент от вътрешната структура на страната за обмен на информация, който описва възможни набори от параметри за сигурност.

Всъщност IPSec, който ще стане част от IPv6, работи на третия слой, т.е. на мрежовия слой. В резултат на това предаваните IP пакети ще бъдат защитени по начин, който е прозрачен за мрежовите приложения и инфраструктура. За разлика от SSL (Secure Socket Layer), който работи на четвъртия (т.е. транспортен) слой и е по-тясно свързан с по-високите слоеве на OSI модела, IPSec е проектиран да осигурява ниско ниво на сигурност.


Ориз. 2 - OSI / ISO модел.

IPSec добавя заглавка към IP данни, готови за изпращане през VPN, за идентифициране на защитени пакети. Преди да бъдат предадени по интернет, тези пакети се капсулират в други IP пакети. IPSec поддържа няколко вида криптиране, включително Data Encryption Standard (DES) и Message Digest 5 (MD5).

За да установят защитена връзка, и двамата участници в сесията трябва да могат бързо да се споразумеят относно параметрите за сигурност, като например алгоритми за удостоверяване и ключове. IPSec поддържа два типа схеми за управление на ключове, чрез които участниците могат да договарят параметрите на сесията. Тази двойна поддръжка предизвика известни търкания в работната група на IETF по това време.

С текущата версия на IP, IPv4, може да се използва или Internet Secure Association Key Management Protocol (ISAKMP), или Simple Key Management for Internet Protocol. СЪС нова версия IP, IPv6, ще трябва да използва ISAKMP, сега известен като IKE, въпреки че не е изключена възможността за използване на SKIP. Все пак трябва да се има предвид, че SKIP вече не се счита за ключов кандидат за управление и беше премахнат от списъка с възможни кандидати още през 1997 г.

AH заглавка

Заглавието за удостоверяване (AH) е нормално незадължително заглавие и обикновено се намира между заглавието на основния IP пакет и полето за данни. Наличието на AH не влияе на процеса на прехвърляне на информация на транспортния и по-високите слоеве. Основната и единствена цел на AH е да осигури защита срещу атаки, свързани с неоторизирани промени в съдържанието на пакета, включително подправяне на оригиналния адрес на мрежовия слой. Протоколите от по-високо ниво трябва да бъдат модифицирани, за да се извърши проверка на автентичността на получените данни.

Форматът AH е доста прост и се състои от 96-битов хедър и данни с променлива дължина от 32-битови думи. Имената на полетата отразяват съдържанието им доста ясно: Next Header показва следващото заглавие, Payload Len представлява дължината на пакета, SPI е указател към контекста на сигурността, а полето Sequence Number съдържа поредния номер на пакета.


Ориз. 3 - AH формат на заглавката.

Поредният номер на пакета беше въведен в AH през 1997 г. по време на процеса на преразглеждане на IPsec спецификацията. Стойността на това поле се генерира от подателя и служи за защита срещу атаки, свързани с повторно използванеданни за процеса на удостоверяване. Тъй като интернет не гарантира реда, в който пакетите ще бъдат доставени, получателят трябва да пази информация за максималния пореден номер на пакет, който е бил успешно удостоверен, и за получаването на определен брой пакети, съдържащи предишни поредни номера (обикновено този номер е 64).

За разлика от алгоритмите за изчисляване на контролната сума, използвани в протоколите за предаване на информация по комутируеми комуникационни линии или по LAN канали и фокусирани върху коригиране на случайни грешки в предавателната среда, механизмите за интегритет на данните в отворените телекомуникационни мрежи трябва да имат средства за защита срещу извършване на целеви промени . Един от тези механизми е специално приложение на алгоритъма MD5: по време на формирането на AH хеш функцията се изчислява последователно от комбинацията на самия пакет и някакъв предварително съгласуван ключ, а след това от комбинацията на резултата и трансформирания ключ. Този механизъмсе прилага по подразбиране, за да се осигурят всички реализации на IPv6 с поне един общ алгоритъм, който не подлежи на експортни ограничения.

ESP заглавка

В случай на капсулиране на криптирани данни, ESP хедърът е последният от незадължителните хедъри, "видими" в пакета. Тъй като основната цел на ESP е да гарантира поверителността на данните, различните видове информация може да изискват използването на значително различни алгоритми за криптиране. Следователно форматът ESP може да претърпи значителни промени в зависимост от използваните криптографски алгоритми. Могат обаче да бъдат разграничени следните задължителни полета: SPI, указващ контекста на сигурността, и поле Sequence Number, съдържащо поредния номер на пакета. Полето „ESP Authentication Data“ (контролна сума) не е задължително в заглавката на ESP. Получателят на ESP пакета декриптира ESP хедъра и използва параметрите и данните на приложения алгоритъм за криптиране, за да декодира информацията на транспортния слой.


Ориз. 4 - ESP формат на заглавката.

Има два режима на приложение на ESP и AH (както и техните комбинации) - транспортен и тунелен.

Транспортен режим

Транспортният режим се използва за криптиране на полето с данни на IP пакет, съдържащ протоколи на транспортния слой (TCP, UDP, ICMP), който от своя страна съдържа информация за услугата на приложението. Пример за приложение на транспортен режим е предаването електронна поща. Всички междинни възли по пътя на пакета от изпращача до получателя използват само информация за публичния мрежов слой и евентуално някои незадължителни заглавки на пакети (в IPv6). Недостатъкът на транспортния режим е липсата на механизми за скриване на конкретния подател и получател на пакета, както и възможността за анализ на трафика. Резултатът от такъв анализ може да бъде информация за обема и посоката на трансфер на информация, областите на интерес на абонатите, местоположението на мениджърите.

тунелен режим

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

Асоциации за сигурност

Асоциацията за сигурност (SA) е връзка, която предоставя услуги за сигурност за трафика, който преминава през нея. Двата компютъра от всяка страна на SA съхраняват режима, протокола, алгоритмите и ключовете, използвани в SA. Всеки SA се използва само в една посока. За двупосочна комуникация са необходими две SA. Всеки SA изпълнява един режим и протокол; по този начин, ако трябва да се използват два протокола (като AH и ESP) за един пакет, тогава са необходими два SA.

Политика за сигурност

Политиката за сигурност се съхранява в SPD (база данни за политика за сигурност). SPD може да укаже едно от трите действия за пакет от данни: отхвърляне на пакета, не обработване на пакета чрез IPSec, обработка на пакета чрез IPSec. В последния случай SPD също така указва кой SA да се използва (приемайки, че вече е създаден подходящ SA, разбира се) или указва с какви параметри трябва да бъде създаден нов SA.

SPD е много гъвкав контролен механизъм, който позволява много добър контрол върху обработката на всеки пакет. Пакетите се класифицират по голям брой полета и SPD може да провери някои или всички полета, за да определи подходящото действие. Това може да доведе до това, че целият трафик между две машини се изпраща с помощта на един SA или отделни SA се използват за всяко приложение или дори за всяка TCP връзка.

ISAKMP/Оукли

Протоколът ISAKMP дефинира цялостна структурапротоколи, които се използват за създаване на SA и за изпълнение на други ключови функции за управление. ISAKMP поддържа няколко домейна на интерпретация (DOI), един от които е IPSec-DOI. ISAKMP не дефинира пълен протокол, но предоставя "градивни елементи" за различни DOI и протоколи за обмен на ключове.

Протоколът Oakley е протокол за определяне на ключ, който използва алгоритъма за заместване на ключ Diffie-Hellman. Протоколът Oakley поддържа Perfect Forward Secrecy (PFS). Наличието на PFS означава, че целият трафик не може да бъде дешифриран, ако някой ключ в системата е компрометиран.

IKE

IKE е протоколът за обмен на ключове по подразбиране за ISAKMP и в момента е единственият. IKE се намира на върха на ISAKMP и извършва действителното установяване както на ISAKMP SA, така и на IPSec SA. IKE поддържа набор от различни примитивни функции за използване в протоколи. Сред тях са хеш функцията и псевдослучайната функция (PRF).

Хеш функцията е функция, която е устойчива на сблъсъци. Устойчивостта на сблъсък се отнася до факта, че е невъзможно да се намерят две различни съобщения m 1И м2, така че H(m1)=H(m2), Където з- хеш функция.

По отношение на псевдослучайните функции, понастоящем, вместо специални PRF, в дизайна на HMAC се използва хеш функция (HMAC е механизъм за удостоверяване на съобщения, използващ хеш функции). За да дефинираме HMAC, имаме нужда от криптографска хеш функция (означена като H) и таен ключ K. Предполагаме, че H е хеш функция, при която данните се хешират с помощта на процедура за компресиране, приложена последователно към поредица от блокове данни. Ще обозначим с B дължината на такива блокове в байтове, а дължината на блоковете, получени в резултат на хеширане като L (L

Ipad = байт 0x36 повторен B пъти;
opad = байт 0x5C повторен B пъти.

За да изчислите HMAC от "текстови" данни, трябва да извършите следната операция:

H(K XOR opad, H(K XOR ipad, текст))

От описанието следва, че IKE използва HASH стойности за удостоверяване на страните. Обърнете внимание, че HASH в този случай се отнася изключително до името на Payload в ISAKMP и това име няма нищо общо с неговото съдържание.

Атаки срещу AH, ESP и IKE.

Всички видове атаки срещу IPSec компоненти могат да бъдат разделени на следните групи: атаки, които използват ограничеността на системните ресурси (типичен пример е атака за отказ на услуга, атака за отказ на услуга или DOS атака), атаки, които използват функциите и грешки на конкретна реализация на IPSec и накрая атаки, базирани на слабостите на самите протоколи. AH и ESP. Чисто криптографските атаки могат да бъдат игнорирани - и двата протокола дефинират концепцията за "трансформации", където цялата криптография е скрита. Ако използваният криптоалгоритъм е устойчив и дефинираната с него трансформация не въвежда допълнителни слабости (това не винаги е така, затова е по-правилно да се вземе предвид стабилността на цялата система - протокол-трансформация-алгоритъм), тогава от това страна всичко е наред. Какво остава? Replay Attack - изравнява се чрез използване на Sequence Number (в един единствен случай това не работи - при използване на ESP без удостоверяване и без AH). Освен това редът на действията (първо криптиране, след това удостоверяване) гарантира бързо отхвърляне на "лоши" пакети (още повече, според последните изследвания в света на криптографията, това е най-сигурният ред на действия, обратният ред в някои , макар и много специални случаи, може да доведе до потенциални дупки в сигурността; за щастие нито SSL, нито IKE, нито други общи протоколи с протокол „първо удостоверяване, след това криптиране“ не принадлежат към тези специални случаи и следователно нямат тези дупки ). Това, което остава, е атаката за отказ от услуга. Както знаете, това е атака, срещу която няма пълна защита. Въпреки това, бързото отхвърляне на лоши пакети и липсата на каквато и да е външна реакция към тях (според RFC) правят възможно справянето с тази атака повече или по-малко добре. По принцип повечето (ако не всички) известни мрежови атаки (снифинг, спуфинг, отвличане и т.н.) се противопоставят успешно от AH и ESP, когато се използват правилно. С IKE е малко по-сложно. Протоколът е много сложен, труден за анализ. В допълнение, поради правописни грешки (във формулата за изчисляване на HASH_R) при писането му и не напълно успешни решения (същите HASH_R и HASH_I), той съдържа няколко потенциални „дупки“ (по-специално, не всички полезни товари в съобщението са удостоверени в първа фаза), обаче, те не са много сериозни и водят най-много до отказ за установяване на връзка. IKE е повече или по-малко успешно защитен от атаки като повторно възпроизвеждане, подправяне, снифинг, отвличане. Криптографията е малко по-сложна - не се изобразява, както в AH и ESP, отделно, а е внедрена в самия протокол. Въпреки това, когато използвате постоянни алгоритми и примитиви (PRF), не би трябвало да има проблеми. До известна степен може да се счита за слабост на IPsec това, че DES е посочен като единственият задължителен криптоалгоритъм за внедряване в текущите спецификации (това важи както за ESP, така и за IKE), 56 бита от ключа на който вече не се вземат предвид достатъчно. Въпреки това, това е чисто формална слабост - самите спецификации са независими от алгоритъма и почти всички известни доставчици отдавна са внедрили 3DES (а някои вече са внедрили AES). Така, ако се внедри правилно, отказът от обслужване остава най-„опасната“ атака.

Оценка на протокола

Протоколът IPSec получи смесени отзиви от експерти. От една страна се отбелязва, че протоколът IPSec е най-добрият сред всички други протоколи за защита на данни, предавани по мрежата, разработени по-рано (включително разработения от Microsoft PPTP). Според другата страна има прекомерна сложност и излишък на протокола. Например Niels Ferguson и Bruce Schneier в своята работа „Криптографска оценка на IPsec“ отбелязват, че са открили сериозни проблеми със сигурността в почти всички основни компоненти на IPsec. Тези автори също така посочват, че пакетът от протоколи се нуждае от много работа, за да осигури добро ниво на сигурност. Документът описва редица атаки, които използват както слабостите на общата схема за обработка на данни, така и слабостите на криптографските алгоритми.

Заключение

В тази статия разгледахме някои от основните точки относно протокола за мрежова сигурност IPsec. Струва си да се отбележи, че IPsec доминира в повечето реализации на виртуални частни мрежи. В момента на пазара са представени и двете софтуерни реализации (например протоколът е внедрен в операционната система Microsoft Windows2000), а софтуерните и хардуерните реализации на IPsec са решения на Cisco, Nokia. Въпреки големия брой различни решения, всички те са доста добре съвместими помежду си. Статията завършва с таблица, която сравнява IPSec и сега широко използвания SSL.

Особености IPSec SSL
Хардуерна независимост да да
Код Не са необходими промени за приложенията. Може да изисква достъп до изходния код на TCP/IP стека. Необходими са промени в приложението. Може да са необходими нови DLL файлове или достъп до изходния код на приложението.
защита Цял IP пакет. Активира защита за протоколи от по-висок слой. Само приложен слой.
Филтриране на пакети Въз основа на удостоверени заглавки, адреси на изпращач и получател и др. Просто и евтино. Подходящ за рутери. Въз основа на съдържание и семантика от високо ниво. По-интелигентен и по-сложен.
производителност По-малко превключвания на контекст и движение на данни. Повече превключвания на контекст и движение на данни. Големите блокове от данни могат да ускорят криптографските операции и да осигурят по-добро компресиране.
Платформи Всякакви системи, включително рутери По принцип крайни системи (клиенти/сървъри), също и защитни стени.
Защитна стена/VPN Целият трафик е защитен. Само трафикът на ниво приложение е защитен. ICMP, RSVP, QoS и др. може да не са защитени.
Прозрачност За потребители и приложения. Само за потребители.
Актуално състояние нововъзникващ стандарт. Широко използван от WWW браузъри, използван и от някои други продукти.

Връзки

  • www.ietf.org/html.charters/ipsec-charter.html - Начална страница на работната група на IETF. Има и връзки към RFC и предложения за стандарти.
  • www.microsoft.com/rus/windows2000/library/security/w2k_IPSecurity.asp - Информация за внедряването на IPSec протокола в Windows2000 Server.

Благодаря

Във връзка с

Съученици



Зареждане...
Връх