Установка IPSEC соединения между компьютерами Linux (FreeS/WAN) и Windows в Transport Mode c использованием PSK.

ipsec.conf

# basic configuration
config setup
    interfaces="ipsec0=<интерфейс>"
    klipsdebug=none
    plutodebug=none
    plutoload=%search
    plutostart=%search
    uniqueids=yes

conn lin-win
    left=<linux_ip>
    right=<windows_ip>
    type=transport
    pfs=no
    auth=esp
    auto=start

Далее делаем:

echo "0" > /proc/sys/net/ipv4/conf/<интерфейс>/rp_filter

или

sysctl -w 'net.ipv4.conf.<интерфейс>.rp_filter=0'

это у нас отключает так называемый Reverse Path Filtering или как его еще называют "Back Route Verify ". Принцип действия этого механизма: фильтр проверяет адрес источника пакета, пришедшего на сетевой интерфейс, просматривая таблицы маршрутизации, и если для отправки ответа на этот пакет роутер должен будет использовать другой интерфейс - пакет отбрасывается, т.к. фильтр считает, что происходит ip spoofing. То есть rp_filter будет отбрасывать корректные пакеты в среде, содержащей ассиметричный роутинг. Мы эту штуку отключаем, что в принципе иногда ужасает некоторых товарищей, хотя ничего страшного нет.
Что бы все было нормально нужно:

1. при настройке внимательно читать документацию
2. устанавливать политики IPSEC Require! чтоб незашифрованный трафик был просто-напросто запрещен
3. использовать такую замечательную вещь как iptables, которая умеет выбирать пакеты не только по портам и адресам, но и по протоколам! (и я надеюсь, вы обычно настраиваете защиту от IP Spoofing)
4. использовать еще более замечательную вещь - голову =) эта вещь даже круче iptables! Пользуйтесь!

Теперь небольшой, но очень симпатичный финт ушами =) Если у нас linux машина одновременно является гейтвейем windows машины, то. .то информация предназначенная непосредственно linux машине посылается как и положено, зашифрованная IPSEC, а информация, которая должна маршрутизироваться пересылается в незашифрованном виде (учитывая, что это транспортный режим, я вроде ничего удивительного не сказал, вроде оно так и должно быть - типа "трава зеленая"). А теперь пробуем пинговать что-нибудь далекое. Ха! Шутка! Пакеты идут так: windows ---> <interface> ---> internet ---> <ipsec> ---> windows, то есть незашифрованные пакеты для маршрутизации отсылаются linux машине на обычный интерфейс, а из Интернета linux возвращает их через ipsec интерфейс. Это фича. Поэтому те, кому надо делают например так:

iptables -t mangle -A PREROUTING -i <внешний интефейс> -j MARK --set-mark 1
ip rule add fwmark 1 table 100
ip route add table 100 dev <interface>

, где <interface> - интерфейс, на который вешали ipsec и <внешний интефейс> - это интерфейс подключенный к другим сетям. (в моем случае такими интерфейсами являлись eth0, eth1 и все ppp - ppp+ )

к оглавлению
 

Открываем Control-Panel -> Administrative Tools -> Local Security Policy и щелкаем правой кнопкой мышки на IP Security Polices on Local Computer, как это показано на рис.1. Затем выбираем меню Create IP Security Policy. На вкладке IP Security Policy Name задайте любое понятное вам название - например "win-lin". Оставляем пункт Activate the default response rule выбранным. На вкладке Default Response Rule Authentication Method выбираем опцию Use this string to protect the key exchange (preshared key) и задаем наш <key>, как это показано на рис.2 и создаем политику.

к оглавлению
 

На вкладке <Имя> Properties нажимаем кнопку Add и добавляем новое правило как это показано на рис.3. На вкладке Tunnel End point ничего не трогаем - оставляем выбранным правило This rule does not specify a tunnel (все-таки мы настраивает транспортный режим, а не туннельный). На вкладке Network Type выбираем Local area network (LAN). Затем на вкладке Authentication Method выбираем опцию Use this string to protect the key exchange (preshared key) и задаем наш <key>.

к оглавлению
 

На вкладке IP Filter List выбираем Add и добавляем новый фильтр. У вас должно появиться окно аналогичное рис.4. Выбираем имя фильтра и нажимаем Add, после чего появляется IP Filter Wizard. На вкладке IP Traffic source оставляем выбранным вариант My IP Address, а на вкладке IP Traffic Destination выбираем A specific IP Address, как это показано на рис.5. и задаем <linux_ip>. Вкладку IP Protocol Type не трогаем(оставляем any) и создаем фильтр. Должно получиться что-то типа рис.6. и затем выбираем вновь созданный фильтр на вкладке IP Filter List.

к оглавлению
 

На вкладке Filter Action, которая служит для определения действий, происходящих при попытках зашифрованных/не зашифрованных соединений, создаем новый фильтр, нажав на кнопку Add. На вкладке Filter Action Name задаем имя фильтра. На вкладке Filter Action General Option оставляем Negotiate security. На вкладке Communicating with computer that do not support IPSec оставляем выбранной опцию Do not communicate with computer that do not support IPSec, как это показано на рис.7. На следующей вкладке IP Traffic Security выбираем пункт Custom и нажимаем на кнопку Settings, и выбираем, соответственно, алгоритм ответственный за целостность данных MD5, а алгоритм ответственный за шифрование 3DES - рис.8. Session key settings - добавить по вкусу, однако, лучше не перебарщивать. Создаем фильтр и выбираем его на вкладке Filter Action. И, наконец то, создаем правило безопасности.

к оглавлению
 

Если вы все правильно сделали (должно получиться что-то вроде рис.9) и запустили IPSEC на машине с linux, то у вас скоро все заработает. Закрываем вкладку <Имя> Properties, нажав на кнопку Close.

к оглавлению
 

В linux'e даем команду /etc/init.d/ipsec start. В windows'е щелкаем правой кнопкой мыши на наше вновь созданное правило и активируем его, выбрав пункт Assign, рис.10 Параллельно в windows'e вы можете пустить ping и если пошли строчки Negotiating IP Security, то значит, системы выбирают общие типы шифрования. Если строки Negotiating IP Security не прекращаются, то вы что-то не так сделали. Обратите внимание на параметр pfs - на компьютерах, устанавливающих связь, он должен иметь одинаковые значения и т.д. - смотрите логи, разбирайтесь. Если же все заработало, то компьютеры видят друг друга идеально. Вы можете убедиться, что IPSEC действительно заработал, используя оснастку IP Security Monitor в WinXP, как это показано на рис.11. или утилиту ipsecmon.exe в win2k, или что-либо еще на ваш выбор (например, Network Monitor).

Процесс установки IPSEC соединения под linux'ом выглядит так:

Выдержка из message.log

Feb 13 12:49:05 obelisk ipsec_setup: Starting FreeS/WAN IPsec 1.99...
Feb 13 12:49:05 obelisk ipsec_setup: Using /lib/modules/2.4.24/kernel/net/ipsec/ipsec.o
Feb 13 12:49:05 obelisk klips_info:ipsec_init: KLIPS startup, FreeS/WAN IPSec version: 1.99
Feb 13 12:49:05 obelisk ipsec_setup: KLIPS debug `none'
Feb 13 12:49:05 obelisk ipsec_setup: KLIPS ipsec0 on homelan <linux_ip>/255.255.255.0 broadcast 10.255.255.255
Feb 13 12:49:05 obelisk ipsec__plutorun: Starting Pluto subsystem...
Feb 13 12:49:05 obelisk ipsec_setup: ...FreeS/WAN IPsec started
Feb 13 12:49:05 obelisk pluto[17066]: Starting Pluto (FreeS/WAN Version 1.99)
Feb 13 12:49:05 obelisk pluto[17066]: added connection description "win-lin"
Feb 13 12:49:05 obelisk pluto[17066]: listening for IKE messages
Feb 13 12:49:05 obelisk pluto[17066]: adding interface ipsec0/homelan <linux_ip>
Feb 13 12:49:05 obelisk pluto[17066]: loading secrets from "/etc/ipsec.secrets"
Feb 13 12:49:05 obelisk pluto[17066]: "win-lin" #1: initiating Main Mode
Feb 13 12:49:11 obelisk pluto[17066]: packet from <windows_ip>:500: ignoring Vendor ID payload
Feb 13 12:49:11 obelisk pluto[17066]: "win-lin" #2: responding to Main Mode
Feb 13 12:49:11 obelisk pluto[17066]: "win-lin" #2: sent MR3, ISAKMP SA established
Feb 13 12:49:11 obelisk pluto[17066]: "win-lin" #3: responding to Quick Mode
Feb 13 12:49:11 obelisk pluto[17066]: "win-lin" #3: IPsec SA established
Feb 13 12:49:15 obelisk pluto[17066]: "win-lin" #1: ignoring Vendor ID payload
Feb 13 12:49:15 obelisk pluto[17066]: "win-lin" #1: ISAKMP SA established
Feb 13 12:49:15 obelisk pluto[17066]: "win-lin" #4: initiating Quick Mode PSK+ENCRYPT+DISABLEARRIVALCHECK
Feb 13 12:49:15 obelisk pluto[17066]: "win-lin" #4: IKE message has the Commit Flag set but Pluto doesn't implement this feature; ignoring flag
Feb 13 12:49:15 obelisk pluto[17066]: "win-lin" #4: ignoring informational payload, type IPSEC_RESPONDER_LIFETIME
Feb 13 12:49:15 obelisk pluto[17066]: "win-lin" #4: sent QI2, IPsec SA established
Feb 13 12:49:15 obelisk pluto[17066]: "win-lin" #4: IKE message has the Commit Flag set but Pluto doesn't implement this feature; ignoring flag
Feb 13 12:49:15 obelisk pluto[17066]: "win-lin" #4: message ignored because it contains an payload type (ISAKMP_NEXT_HASH) unexpected in this message
Feb 13 12:49:15 obelisk pluto[17066]: "win-lin" #2: ignoring Delete SA payload
Feb 13 12:49:15 obelisk pluto[17066]: "win-lin" #2: received and ignored informational message
Feb 13 12:49:15 obelisk ipsec__plutorun: 104 "win-lin" #1: STATE_MAIN_I1: initiate
Feb 13 12:49:15 obelisk ipsec__plutorun: 010 "win-lin" #1: STATE_MAIN_I1: retransmission; will wait 20s for response
Feb 13 12:49:15 obelisk ipsec__plutorun: 003 "win-lin" #1: ignoring Vendor ID payload
Feb 13 12:49:15 obelisk ipsec__plutorun: 106 "win-lin" #1: STATE_MAIN_I2: sent MI2, expecting MR2
Feb 13 12:49:15 obelisk ipsec__plutorun: 108 "win-lin" #1: STATE_MAIN_I3: sent MI3, expecting MR3
Feb 13 12:49:15 obelisk ipsec__plutorun: 004 "win-lin" #1: STATE_MAIN_I4: ISAKMP SA established
Feb 13 12:49:15 obelisk ipsec__plutorun: 112 "win-lin" #4: STATE_QUICK_I1: initiate
Feb 13 12:49:15 obelisk ipsec__plutorun: 003 "win-lin" #4: ignoring informational payload, type IPSEC_RESPONDER_LIFETIME
Feb 13 12:49:15 obelisk ipsec__plutorun: 004 "win-lin" #4: STATE_QUICK_I2: sent QI2, IPsec SA established


Вывод tcpdump:

19:39:03.810739 <windows_ip> > <linux_ip>: ESP(spi=0x356646be,seq=0xd4c) (DF)
19:39:03.811865 <linux_ip> > <windows_ip>: ESP(spi=0x110d41a7,seq=0xde0) (DF) [tos 0x10]
19:39:03.811839 <windows_ip> > <linux_ip>: ESP(spi=0x356646be,seq=0xd4d) (DF)
19:39:03.812325 <windows_ip> > <linux_ip>: ESP(spi=0x356646be,seq=0xd4e) (DF)


Вывод ipsec look:

ipsec look
obelisk Fri Feb 13 12:56:31 MSK 2004
<linux_ip>/32 -> <windows_ip>/32 => esp0x25e409d0@<windows_ip> (0)
ipsec0->homelan mtu=16260(1500)->1500
esp0x25e409d0@<windows_ip> ESP_3DES_HMAC_MD5: dir=out src=<linux_ip> iv_bits=64bits iv=0x51fd9266fb73823c ooowin=64 alen=128 aklen=128 eklen=192 life(c,s,h)=addtime(436,0,0)
esp0x722533e4@<windows_ip> ESP_3DES_HMAC_MD5: dir=out src=<linux_ip> iv_bits=64bits iv=0xe9fbc10da8750ac4 ooowin=64 alen=128 aklen=128 eklen=192 life(c,s,h)=addtime(440,0,0)
esp0x72bdf8a9@<linux_ip> ESP_3DES_HMAC_MD5: dir=in src=<windows_ip> iv_bits=64bits iv=0xffda9d19aae5b094 ooowin=64 seq=75 bit=0xffffffffffffffff alen=128 aklen=128 eklen=192 life(c,s,h)=bytes(4350,0,0)addtime(440,0,0)usetime(440,0,0)packets(75,0,0) idle=436
esp0x72bdf8aa@<linux_ip> ESP_3DES_HMAC_MD5: dir=in src=<windows_ip> iv_bits=64bits iv=0x9f82063ca057de6e ooowin=64 seq=7162 bit=0xffffffffffffffff max_seq_diff=1 alen=128 aklen=128 eklen=192 life(c,s,h)=bytes(445730,0,0)addtime(436,0,0)usetime(436,0,0)packets(7162,0,0) idle=0
Destination Gateway Genmask Flags MSS Window irtt Iface
<nat_ip> 0.0.0.0 255.255.255.0 U 0 0 0 homelan
<net_ip> 0.0.0.0 255.255.255.0 U 0 0 0 ipsec0
<windows_ip> <windows_ip> 255.255.255.255 UGH 0 0 0 ipsec0


к оглавлению
 

Для начала давайте посмотрим, что сделано и что мы должны были сделать. Мы установили IPSEC соединение, обеспечивающие шифрование между двумя нашими компьютерами. Вроде бы мы добились своей цели, однако все зависит от ситуации. Для уменьшения нештатных ситуаций (это когда все куда-то бегут и отовсюду слышится: "хакают! хакают!", хотя большинство спортсменов-бегунов имеют об этом весьма туманные представления) необходимо обязательно установить защиту от IP спуфинга на интерфейсах с выключенными rp_filter'ми. Потом мы должны быть уверенны, что наши сервера будут взаимодействовать только средствами IPSEC. В windows это может быть обеспечено отключением опции Allow unsecured communication with non-IPSec-aware computer и Accept unsecured communication, but always respond using IPSec в политике безопасности IPSEC. В linux это обеспечивается опцией auto=start, которая автоматически запускает шифрованный туннель и фильтрацией трафика с помощью iptables, разрешая взаимодействие только с помощью IPSEC, отбрасывая нешифрованный трафик:

iptables -A INPUT -p udp -i <интерфейс> -s <windows_ip> --sport 500 --dport 500 -j ACCEPT
iptables -A OUTPUT -p udp -o <интерфейс> -d <windows_ip> --sport 500 --dport 500 -j ACCEPT

iptables -A INPUT -p esp -i <интерфейс> -s <windows_ip> -j ACCEPT
iptables -A OUTPUT -p esp -o <интерфейс> -d <windows_ip> -j ACCEPT

iptables -A INPUT -i <интерфейс> -s <windows_ip> -j DROP
iptables -A OUTPUT -o <интерфейс> -d <windows_ip> -j DROP


Если необходимо, то можно добавить:

iptables -A INPUT -p ah -i <интерфейс> -s <windows_ip> -j ACCEPT
iptables -A OUTPUT -p ah -o <интерфейс> -d <windows_ip> -j ACCEPT


Так же можно добавить пару правил IDS, чтобы при обнаружении нешифрованных пакетов, не имеющих отношения к ipsec, но имеющих отношение к нашим серверам, нам выдавалось предупреждение, т.к. наличие такого типа трафика является, скорее всего, следствием любопытства какого-нибудь неосторожного травоядного животного. После того как мы разобрались со спуфингом можно вспомнить, что длинна ключа HMAC-MD5 128 бит, а длинна HMAC-SHA1 160 бит. Учитывая что в FreeS/WAN по умолчанию включена возможность автоматического выбора типа хеширования мы можем установить в windows SHA1 вместо MD5. Тогда команда ipsec look будет выдавать нам вместо ESP_3DES_HMAC_MD5 - ESP_3DES_HMAC_SHA1. Также необходимо не забывать о такой возможности как pfs. PFS (Perfect Forward Secrecy) - такая криптосистема, где шифрованный текст не дает никакой информации об открытом тексте, возможно, за исключением его длины. Это гарантия того, что (в случае асимметричного шифрования) временный ключ, вычисленный на основе открытых и секретных ключей, не будет раскрыт, даже если какой-либо из секретных ключей будет скомпрометирован. В linux'е выставляем опцию pfs=yes, в windows'e включаем master key perfect forward secrecy и session key perfect forward secrecy. Ну и напоследок давайте разберемся, через какой промежуток времени будут меняться наши ключи. Если вы внимательно смотрели логи, то могли заметить строку "ignoring informational payload, type IPSEC_RESPONDER_LIFETIME". Эта строка говорит о том, что удаленная сторона (FreeS/WAN) не хочет менять ключ, а надо бы (вольный перевод изысканий Gerrit Hannaert). Применительно к Checkpoint FW рекомендуется в FreeS/WAN установить время жизни ключа несколько меньше, чем в удаленной системе. Думаю аналогичные рекомендации можно дать и для работы с windows. То есть если вы указали в windows время жизни ключа 60 min, добавьте в ipsec.conf опцию keylife=59m (производить смену ключа через 59 минут) и все будет ok. При желании, вы можете устанавливать ipsec соединения, используя сертификаты, а не PSK. Процедура установки соединений c использованием сертификатов достаточно подробно описана в интернете для туннельного режима. Настройка транспортного режима ipsec, использующего сертификаты - аналогична. Вот вроде бы и все.

Партнёры:

Хостинг: