Посмотреть логи ipsec linux

Где это ваше секретное слово (PSK — publicly shared key),

Часть практическая windows’овая, в которой мы ничего не делаем, кроме настройки IPSEC соединения.

Создаем политику безопасности IPSEC

Добавляем правило безопасности в нашу политику.

Добавляем фильтр для трафика, который будем шифровать.

Добавляем фильтр действий (Filter Action).

Заключительная настройка IPSEC.

Часть кульминационная, в которой мы запускаем IPSEC соединение.

Выдержка из 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

19:39:03.810739 >

Вывод ipsec look:

ipsec look
obelisk Fri Feb 13 12:56:31 MSK 2004

Часть заключительная, в которой мы рассуждаем о том, что еще хорошо бы сделать для сохранности нашего бочонка с медом.

Для начала давайте посмотрим, что сделано и что мы должны были сделать. Мы установили 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 —sport 500 —dport 500 -j ACCEPT
iptables -A OUTPUT -p udp -o -d —sport 500 —dport 500 -j ACCEPT

iptables -A INPUT -p esp -i -s -j ACCEPT
iptables -A OUTPUT -p esp -o -d -j ACCEPT

iptables -A INPUT -i -s -j DROP
iptables -A OUTPUT -o -d -j DROP

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

iptables -A INPUT -p ah -i -s -j ACCEPT
iptables -A OUTPUT -p ah -o -d -j ACCEPT

Источник

IPsec в Linux

Материал из Xgu.ru

Данная страница находится в разработке. Эта страница ещё не закончена. Информация, представленная здесь, может оказаться неполной или неверной.

Если вы считаете, что её стоило бы доработать как можно быстрее, пожалуйста, скажите об этом.

Содержание

[править] Конфигурация ядра

Для работы IPSEC необходима поддержка со стороны ядра Linux.

Поддержка протоколов AH, ESP и IPComp (сжатие данных), а так же транспортного, тоннельного и BEET (Bound End-to-End Tunnel) режимов включается следующими опциями (для IPv4 и IPv6 соответственно):

Так же, существуют модули для поддержки IPSec в NetFilter:

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

[править] Необходимые программы

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

ipsec-tools — Универсальный пакет программ для конфигурирования IPSec (так же существуют версии под другие операционные системы, что является большим плюсом), но несколько проигрывает по возможностям iproute2. iproute2 — Позволяет настроить практически все параметры IPSec, которые вообще используются в Linux, включая инкапсуляцию в UDP, что полезно в случае работы через NAT. Racoon/Racoon2/strongSwan — осуществляют поддержку IKE, если Вы будете использовать её. Openssl — необходимо для работы с различными сертификатами.

Если вы используете только статические тоннели, то достаточно средств iproute2.

[править] IPSec и Netfilter

В ядре 2.6 обработка трафика ipsec значительно отличается от того, как это делается в ядре 2.4, в котором присутствует псевдоинтерфейс ipsecX, который является границей раздела между инкапсулированным/зашифрованным трафиком и трафиком в открытом виде. Далее всё описываемое актуально для ядра 2.6. Трафик, подпадающий под политики ipsec, дважды проходит по цепочкам netfilter — в открытом виде и в инкапсулированном/зашифрованным. Не зашифрованный трафик, подпадающий под политики ipsec, проходит по всем цепочкам netfilter сетевого уровня и после цепочки POSTROUTING таблицы nat подвергается шифрованию/инкапсуляции, и уже в инкапсулированном/зашифрованном виде попадает в цепочку OUTPUT таблицы raw, и передаётся далее. Инкапсулированный/зашифрованный же трафик, который подпадает под политики, так же проходит по стандартным цепочкам и уже после цепочки INPUT таблицы filter декапсулируется/расшифровывается, и уже в открытом виде попадает в цепочку PREROUTING таблицы raw, и передаётся далее. Таким образом, трафик можно фильтровать и до, и после инкапсуляции/шифрования.

Netfilter имеет несколько модулей для работы с трафиком ipsec: модули iptables для обработки пакетов протоколов esp и ah, и модули xtables: xt_esp и xt_policy, взаимодействующий с подсистемой xfrm. Так же трафик ipsec можно фильтровать по полям заголовка ip (например, по адресам источника и назначения, номеру протокола, типу обслуживания и времени жизни, и т.п.).

Модули netfilter обработки протоколов ah и esp позволяют задавать условие соответствия по значению поля spi. Не забывайте указывать при использовании этих модулей протокол, иначе получите сообщение об ошибке. Протокол esp имеет номер 50, а ah — 51. Модули поддержки протоколов ipsec (соответствия -m ah и -m esp) позволяют выбирать пакеты на основе значения поля spi. Для соответствия -m ah это опция —ahspi, а для соответствия -m esp это опция —espspi. В качестве параметра используется единственно значение или значения начала и конца непрерывного диапазона, разделённого двоеточием

Следует учесть, что механизм conntrack не может отслеживать пакеты протоколов ipsec, поэтому к ним невозможно применять правила с совпадением по критерию —state. С учётом этого и того, что тоннели ipsec являются однонаправленными, необходимо строить правила так, чтобы разрешить передачу пакетов в обе стороны. Так же эти опции можно использовать для фильтрации транзитного трафика.

Очень большими возможностями в плане фильтрации пакетов ipsec обладает модуль policy, но его действие не распространяется на транзитный трафик ipsec, так как он взаимодействует с подсистемой xfrm. Модуль policy поддерживает соответствие по следующим критериям:

—dir in|out — пакеты, подпадающие под политики декапсуляции|инкапсуляции. —pol none|ipsec — применяемая к пакету политика. —reqid reqid — значение параметра reqid. —spi spi — значение параметра Security Parameters Index. —proto ah|esp|ipcomp — протокол ipsec. —mode transport|tunnel — режим ipsec — транспортный или тоннельный. —tunnel-src addr/mask — адрес источника (только в контексте —mode tunnel). —tunnel-dst addr/mask — адрес назначения (только в контексте —mode tunnel). —next — в одном правиле можно указать несколько политик, эта опция указывает, что далее следует параметры другой политики.

При использовании опций —tunnel-src и —tunnel-dst следует указывать адреса (и маски) именно адреса концов тоннеля (находятся в заголовке пакета ip, в который инкапсулирован пакет). Так же следует учесть, что правила с опцией —dir in недействительны в цепочках POSTROUTING и OUTPUT, а с опцией —dir out в цепочках PREROUTING и INPUT.

Так же, если вы используете какой-либо ike-демон, то соответственно необходимо разрешить udp-пакеты с/на 500 порт. Если же вы используете инкапсуляцию в udp (nat-travesal), то необходимо разрешить udp-пакеты с номером порта 4500.

Так же, если вы используете nat, то в iptables необходимо добавить исключения для трафика IpSec.

Действие RETURN при срабатывании прекращает дальнейшую обработку трафика в данной цепочке и переходит к следующей. Правила nat обрабатываются раньше, чем трафик завернется в IpSec туннель.

[править] Конфигурирование Security Association

Security Association (Безопасная Ассоциация) — это по сути и есть безопасное соединение, обеспечивающее защиту передаваемых данных. На каждом из хостов, между которыми необходимо обеспечить безопасную передачу данных, должны быть созданы безопасные ассоциации для каждого направления. SA содержит такие параметры как адреса узлов/сетей источника и направления, индекс политик безопасности, алгоритмы шифрования/аутентификации и ключи.

Безопасными Ассоциациями можно управлять через утилиту ip, входящую в пакет iproute2. Во многом её возможности шире, чем у setkey. Благодаря сокращениям и единообразному интерфейсу, работать с Безопасными Ассоциациями немного удобнее. Для управления SAD используется конструкция ip xfrm state. Допустимы сокращения наподобие ip x s. В отличии от setkey, который умеет только добавлять и удалять записи SA, ip позволяет их редактировать.

Добавление и изменение записей в SAD осуществляется командой:

ID — идентификатор безопасной ассоциации в SAD. Может состоять из следующих параметров

src ADDR — адрес источника dst ADDR — адрес назначения proto XFRM_PROTO — протокол ipsec (Соответственно может принимать значения ah (authentification header), esp (encrypted security payload), comp (ip compressed payload), route2 (type2 routing header) и hao (home address option). Последние два протокола используются в контексте mobile ipv6). spi SPI — значение security parameter index. mark MARK [mask MASK] — метка и маска пакета (используется при маркировке пакетов с помощью netfilter).

mode transport | tunnel | ro | in_trigger | beet — режим безопасной ассоциации. Соответственно, может принимать одно из значений, означающих транспортный, тоннельный, beet (Bound End-to-End Tunnel), оптимизации маршрута (route optimization) или in_trigger режимы. (последние два используются в контексте mobile ipv6).

reqid REQID — что-то вроде дополнительного идентификатора безопасной ассоциации. Удобно использовать при описании политик, чтобы не описывать шаблон безопасной ассоциации целиком.

seq SEQ — начальное значение sequence номера в пакетах ipsec (по-умолчанию 0).

replay-window SIZE — размер replay-window в пакетах (по-умолчанию имеет значение 32).

replay-seq SEQ и replay-oseq SEQ — значения счётчиков sequence для входящего и исходящего направлений соответственно.

Механизм anti-replay позволяет предотвратить атаки злоумышленников, использующих отправку ранее перехваченных зашифрованных пакетов против уязвимых узлов (так называемая «replay attack»). При выборе значения replay-window следует учесть, что если оно будет слишком маленьким, то в случае, если пакеты будут приходить в другом порядке (вызванном, например, следованием пакетов различными маршрутами или задержками на промежуточных узлах), то «запоздавшие» пакеты могут быть просто отброшены. Так что рекомендуется ставить размер окна как можно большим. При получении узлом зашифрованного пакета, его sequence-номер проверяется на предмет попадания в «окно» и на предмет дубливания с sequence-номерами ранее полученных пакетов. Если sequence-номер пакета больше, чем значение счётчика replay-seq, то пакет принимается и его номер отмечается в специальной битовой маске (replay.bitmap) как полученный; если sequence-номер пакета меньше, чем значение replay-seq — replay-window, то он отбрасывается, если же, он попадает в «окно», то проверяется, был ли получен пакет с таким номером ранее, если да, то он будет так же отброшен. Значения replay-seq, replay-oseq и replay.bitmap обновляются по мере получения пакетов. Так же в механизме учитываются не только сами sequence-номера пакетов, но и время ожидания «запаздывающих» пакетов.

flag FLAG — устанавливает один или несколько флагов опций. Может принимать следующие знячения:

noecn — не использовать механизм явных уведомлений о перегруженности. decap-dscp — учитывать поле DSCP инкапсулированного пакета. Бывает полезно при использовании QOS. nopmtudisc — не выполнять path MTU discovery. wildrecv icmp — разрешить приём icmp-пакетов, полученных через безопасную ассоциацию. Влияет только на входящий шифрованный трафик. af-unspec — позволяет инкапсулировать трафик одного протокола сетевого уровня в ipsec-трафик другого протокола сетевого уровня (например, ipv4 инкапсулировать в ipv6-ipsec). Наиболее актуален при beet-режиме безопасной ассоциации.

encap ENCAP-TYPE SPORT DPORT OADDR — используется для инкапсулирования пакетов протокола esp в udp для решения проблемы с nat. Тут, соответственно, ENCAP-TYPE может принимать значения espinudp или espinudp-nonike, SPORT и DPORT — номера портов источника и назначения, а OADDR — адрес, который будет использован в качестве адреса источника в инкапсулирующих пакетах udp.

limit — устанавливает время жизни (lifetime) безопасной ассоциации. Реализовано два типа: soft — после достижения лимита безопасная ассоциация остаётся в SAD, но система генерирует специальное событие timer expired (это событие обычно обрабатывется демонами ike, а так же будет отображено в режиме мониторинга); и hard — после достижения лимита безопасная ассоциация удаляется из SAD. Команда имеет следующие параметры:

packet-soft | packet-hard PACKETS — время жизни устанавливается количеством пакетов, прошедшим через безопасную ассоциацию. byte-soft | byte-hard BYTES — время жизни устанавливается количеством данных, прошедшим через безопасную ассоциацию. time-soft | time-hard SECONDS — время жизни безопасной ассоциации в секундах с момента добавления в SAD. time-use-soft | time-use-hard SECONDS — время жизни безопасной ассоциации в секундах с момента начала использования, то есть прохождения первого пакета.

sel src ADDR[/PLEN] dst ADDR[/PLEN] proto PROTO [ [ sport PORT ] [ dport PORT ] | [ type NUMBER ] [ code NUMBER ] ] [ dev DEV ] — определяет шаблон пакетов, проходящих через данную безопасную ассоциацию безопасную ассоциацию. Используется для поиска безопасной ассоциации в SAD, в случае если безопасные ассоциации имеют идентичный ID. Задаёт адреса и длину префиксов полей источника и назначения (src ADDR[/PLEN] dst ADDR[/PLEN]), код протокола верхнего уровня (proto PROTO), а так же может содержать другие критерии, например, номера портов (протоколы tcp/udp/sctp/dccp), тип или код сообщения (протокол icmp), а так имя интерфейса, с которого получен пакет, или через который будет отправлен.

Посмотреть информацию о безопасных ассоциациях можно с помощью следующих команд.

Показать безопасные ассоциации, соответствующие заданным параметрам. Так же может использоваться с параметром -s[tatistic], позволяющим отобразить более подробную информацию о безопасной ассоциации.

Количество безопасных ассоциаций в SAD можно проверить командой

Так же можно удалять безопасные ассоциации. Чтобы очистить SAD можно использовать команду

[править] Поддерживаемые криптографические алгоритмы

IPsec позволяет использовать различные алгоритмы для шифрования данных и для проверки целостности передаваемых данных, и аутентификации, при условии, что их поддержка включена в ядро статически или в виде модуля. Если вы ошиблись в названии алгоритма или поддержка со стороны ядра отсутствует, то утилита ip сообщит об ошибке — «RTNETLINK answers: Function not implemented». Так же необходимо учитывать то, что многие алгоритмы работают с ключами фиксированной длины, поэтому если указанный вами ключ будет отличаться по длине от требуемого, то вы получите сообщение об ошибке (в утилите ip это «RTNETLINK answers: Invalid argument»). Ключи можно задавать как в текстовом формате, заключая строку в двойные кавычки, так и в шестнадцатеричном, предваряя ключ символами 0x.

Так же для сжатия данных могут использоваться алгоритмы deflate, lzh, lzjh.

[править] Конфигурирование Security Policy

Security Policy (политики безопасности) определяют, какие именно пакеты будут передаваться с помощью ipsec, а так же, через какие безопасные ассоциации и какие действия к ним должны быть применены. Политики безопасности хранятся в Security Policies Database (База политики безопасности, далее SPD). Управление политиками безопасности так же осуществляется через утилиты setkey или ip (с помощью команд ip xfrm policy).

Добавление или изменение политики безопасности осуществляется командой:

dir DIR — направление движения пакетов, подпадающих под политику. Может принимать значения in — для входящих пакетов, out — для исходящих и fwd — для транзитных.

SELECTOR — шаблон, описывающий, какие пакеты подпадают под действия политики. Может содержать следующие параметры: src ADDR[/PLEN] dst ADDR[/PLEN] proto PROTO [ [ sport PORT ] [ dport PORT ] | [ type NUMBER ] [ code NUMBER ] ] [ dev DEV ]. Имеют такое же значение, как и при описании безопасной ассоциации.

index INDEX — идентификатор политики безопасности в SPD.

ptype PTYPE — тип политики безопасности. Может принимать значения main и sub (по-умолчанию main).

action ACTION — разрешить обработку пакета (allow) или отбросить его (block).

priority PRIORITY — приоритет политики.

limit LIMIT-LIST — время жизни политики. Полностью аналогично параметрам времени жизни безопасной ассоциации.

tmpl TMPL-LIST — шаблон безопасной ассоциации, через которую должен быть передан или получен пакет. Шаблон должен содержать один или несколько параметров [ src ADDR ] [ dst ADDR ] [ proto XFRM_PROTO ] [ spi SPI ] [ mode MODE ] [ reqid REQID ] [ level LEVEL ]. Параметр level принимает значения required (обязательное шифрование) или use (необязательное шифрование), который задаёт действие по отношению к незашифрованным входящим пакетам, подпадающим под политику. Другие параметры аналогичны тем, что используются при описании безопасных ассоциаций.

mark MARK [mask MASK] — метка netfilter пакета, подпадающего под политику.

[править] Конфигурирование IKE в Racoon

[править] Аутентификация с помощью preshared key

[править] Использование сертификатов X.509

[править] NAT-Travesal

[править] Практикум и готовые решения

[править] Конфигурационные файлы для L2TP сервера с IPsec.

Аутентификация будет производиться по сертификатам безопасности.

$EXTADDR — адрес, к которому будут коннектится клиенты. $SERVERCRT.crt и SERVERKEY.key — сертификаты безопасности нашего сервера.

Авторизация только через CHAP. Логины и пароли пользователей должны быть прописаны в chap-secrets.

$BEGRANGE и $ENDRANGE — начальный и конечный адреса клиентского диапазона. $LOCALADDR — адрес шлюза для клиентов.

Указываем адреса днс-серверов. Значение параметра linkname можно использовать в скриптах ip-up и ip-down.

$DNS1 и $DNS2 — айпи-адреса днс-серверов

Прописываем Политики Безопасности для IPsec.

$EXTADDR — адрес, к которому будут подключаться клиенты.

Источник