Анатомия IPsec. Проверяем на прочность легендарный протокол

[farcaller]

А что насчет авторизации по сертификатам?

[AEP]

Работает, но не во всех сетях. Сертификат вместе со всей цепочкой должен влезть в один UDP-пакет. С классическими сертификатами RSA-2048 от общепризнанных удостоверяющих центров, запросто получается UDP-пакет на 5 килобайт, т.е. требуется фрагментация. А некоторые провайдеры режут все фрагменты, чтобы защитить свою сеть от DoS атак. ECDSA-256 от общепризнанных удостоверяющих центров тоже не пролезает (1.8 килобайта), как, впрочем, и самоподписанный RSA-2048 без цепочки. Т.е. единственный невзламываемый вид сертификата, с которым можно избежать необходимости фрагментировать UDP-пакеты на стадии IKE_AUTH — это самоподписанный ECDSA-256.

Да, есть расширение для фрагментации на уровне UDP (RFC 7383), но оно очень свежее и не поддерживается в Windows.

[ValdikSS]

А некоторые провайдеры режут все фрагменты, чтобы защитить свою сеть от DoS атак.

Ох, вы не представляете, сколько МТС обещает починить фрагментированные пакеты на беспроводном интернете! Причем они не ходят во всех регионах, т.е. ping -s 1500 ya.ru вам не вернет ни один пакет в ответ. И, действительно, IPsec не подключается с выключенной внутренней фрагментацией.

RFC 7383 поддерживается, как минимум, в Android. А вот за информацию о том, что в Windows он не поддерживается, спасибо, не знал.

[HunterXXI]

отличная статья, в заголовок стоит добавть ключевое слово Cisco т.к. при объяснении используется синтаксис IOS

[JDima]

В статье говорится про ASA, которая никакого отношения к IOS не имеет. Правда, синтаксис у них похожий, а местами и совсем одинаковый.

[ALTF13]

Синтаксис IOS и ASA не просто так настолько схож, так что отношение друг к другу они очень даже имеют ;) Аналогично и про NX-OS — да, не одно и то же, но тенденции и первоисточники прослеживаются.

[JDima]

Абсолютно разные по внутреннему устройству ОС (IOS, ASA-OS, NX-OS, можно добавить еще IOS-XR, и забывая про существование WLC, CSS/ACE и других категорий продуктов). Их обертку-CLI понемногу сближают друг к другу, ну кроме IOS-XR пожалуй, тот особенный. История у них тоже совершенно разная — IOS изначально был примерно такой, ASA-OS эволюционировал из PIX'ов (разработчик куплен циской, и я до сих пор с содроганием вспоминаю интерфейс 6.Х у пиксов, и что самое страшное — те уродцы до сих пор существуют в моей сети), NX-OS — потомок SAN-OS у MDS.

[ALTF13]

Спасибо, разложили всё по полочкам :)

[ValdikSS]

Не просто добавить Cisco, но и заменить везде IPsec на IPSec (маленькая и большая S). IPsec и Cisco IPSec можно даже, пожалуй, назвать не совсем совместимыми протоколами, т.к. в последнем есть куча проприетарных надстроек.

[Vengant]

Вы описали самый простой кейс.
Интересно было бы узнать, сколько времени приведенными средствами будут подбираться сложные пары логин/пароль для xauth. Крепко сомневаюсь, что их реально подобрать раньше, чем администраторы и/или специалисты ИБ обратят внимание на атаку.
Я уж не говорю об OTP, но большинство вменяемых организаций таки использует авторизацию по сертификатам, а не по group key. Раскрыть бы тему исследования и обхода такой защиты…

[DmitryKoterov]

Да уж, статья из серии «как взломать систему, подобрав пароль qwerty к логину admin», изображающая крутость за ширмой миллиона терминов. При таком пароле (и других параметрах) не очень-то и важно, что там на том конце — ipsec, ssh или хоть http basic auth. Непонятно еще, почему бы на сервере не включить что-то типа fail2ban (если аналогичная штука есть для ipsec — наверняка она есть), которая бы навечно блокировала ip-адрес злоумышленника после N неудачных попыток, а также не поставить задержку в несколько секунд между последовательными запросами с одного ip-адреса. Тогда бы даже подбор qwerty-подобных паролей резко усложнился. А аббревиатур можно сколько угодно насыпать — от числа аббревиатур защищенность системы, к сожалению, не увеличивается.

[AEP]

А собственно почему бы и не сам fail2ban? Да, правила, специфичного для ipsec, в коробке нет, но его можно написать.

[jaraalex]

Автору. Аутентификация происходит либо по PSK, либо по RSA Signature. По MD5/SHA хеширование — проверка целостности, а не аутентификация, как вы написали здесь — " помощью чего аутентифицировать (SHA или MD5)." Но позже вы написали уже верно — «То есть в последнюю очередь идет процесс аутентификации, либо по PSK-, либо по RSA-ключу.». Поправьте в статье, не вводите в заблуждение людей. Но если считаете, что не прав я, то напишите обоснование ответом, мне будет интересно. Может я что не так понял.
А так, статья хороша, Спасибо!