AnyConnect у Linux: безпечне написання сценарію входу

Клієнт vpn, що постачається з Cisco AnyConnect, поводиться як розмова: друкує запрошення, чекає рядок, потім друкує наступне. Якщо подати цю розмову з файлу або каналу, той самий бінарний файл працює без нагляду. Техніка — це одне перенаправлення й упорядкований список відповідей, і саме список, а не перенаправлення, визначає, чи сценарій надійний.

На практиці це ламають дві речі. Порядок запрошень зсувається, коли шлюз запитує щось додаткове, а збережений пароль перетворює одну друкарську помилку на блокування облікового запису. Ставтеся до послідовності як до версійованих даних, які можна порівняти після будь-якої зміни шлюзу. Зазнавайте збою гучно замість повторів, бо цикл — це саме той шлях, яким неправильно набраний пароль стає заблокованим обліковим записом.

Одна послідовність, у тому порядку, у якому запитує клієнт

Запустіть клієнт інтерактивно один раз і запишіть кожне запрошення в порядку появи. Цей запис стає файлом відповідей. Коли ви перенаправляєте файл у бінарний файл, перший рядок має бути самою командою підключення, тому послідовність починається з імені хоста, а не з імені користувача.

connect vpn.example.com
0
<username>
<password>
y
exit

Голий 0 вибирає перший профіль підключення, коли шлюз пропонує список; використовуйте той індекс, який друкує ваш шлюз. y приймає банер входу, тому видаліть цей рядок, якщо банера немає, і вставте його там, де ваш шлюз ставить додаткове запитання. Завершальний exit дає клієнту змогу коректно завершитися, коли останню відповідь використано.

/opt/cisco/anyconnect/bin/vpn -s < anyconnect.txt

Неінтерактивний режим тут не є вибором. Без -s клієнт може захопити термінал і ігнорувати перенаправлене введення; з ним відповіді читаються з потоку і процес повертається. Там, де бінарному файлу потрібні підвищені права, оберніть виклик у sudo -n, щоб сценарій падав одразу, а не зависав на запиті пароля.

Де витікає файл відповідей

Файл із паролем — це облікові дані, тому дайте йому права як обліковим даним: режим 600, власник — обліковий запис, що виконує завдання, і ніколи в спільній або синхронізованій теці. Створюйте його з уже застосованим режимом, а не виправляйте потім, бо файл на мить доступний для читання всім між записом і chmod.

install -m 600 /dev/null ~/.config/anyconnect.txt
chmod 700 ~/.config

Друга половина — це argv. Пароль, переданий аргументом, видно кожному локальному користувачеві, який перелічує процеси, і він також потрапляє до історії оболонки. Читайте його з дескриптора файлу або змінної середовища, і беріть корисне навантаження в лапки, щоб оболонка не могла нічого всередині розгорнути.

printf '%s\n' 'connect vpn.example.com' '0' "$VPN_USER" "$VPN_PASS" 'y' 'exit' \
  | sudo -n /opt/cisco/anyconnect/bin/vpn -s

Стежте за лапками. У подвійних лапках пароль, що містить !, може бути розгорнутий інтерактивною оболонкою ще до того, як клієнт його побачить, і збій приходить як загальна помилка event-not-found, що виглядає як проблема протоколу.

Доведіть тунель, потім закрийте його

Стан підключено доводить лише те, що клієнт вважає, ніби має сеанс. Виберіть хост, який відповідає лише зсередини корпоративної мережі, і перевірте його один раз, перш ніж робити щось інше. Збій там — це дефект маршрутизації або політики, і повторний запуск входу це не змінить.

/opt/cisco/anyconnect/bin/vpn state
curl -sS -o /dev/null -w '%{http_code}\n' --max-time 10 https://<internal-host>/
/opt/cisco/anyconnect/bin/vpn disconnect

Перевірте вивід стану до та після відключення. Клієнт, залишений із застарілим сеансом, може відмовити в наступному підключенні, тоді як сценарій усе ще повідомляє про успіх, і цей режим збою невидимий, якщо дивитися лише на коди виходу. Порівняйте обидва зчитування, а не довіряйте другому окремо. Псевдоніми в профілі оболонки годяться для щоденного використання, а все заплановане заслуговує на такий самий огляд облікових даних і особистості, як будь-яка інша робота без нагляду.

Коли фіксований список перестає бути безпечним

Файл відповідей кодує сьогоднішній порядок запрошень. Змінений банер, примусова зміна пароля або виклик другого фактора перетворюють його на цикл, який може заблокувати обліковий запис, тому сценарій має виходити на першій неочікуваній відповіді, а не перезапускатися.

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

Ротація належить до того самого огляду. Якщо облікові дані зберігаються, вирішіть, хто може їх читати, коли вони змінюються і що видаляє їх під час перебудови хоста. Сценарій, який працює рік, бо ніхто не торкався пароля, — це не проєкт, а пригода, що чекає на політику ротації.

Профілі, які не AnyConnect

Два старіші стилі облікових даних Cisco плутають із цим. Профіль vpnc запитує IPSec ID, що насправді є іменем групи, потім групову таємницю, потім ваші власні облікові дані, і всі три походять від того, хто керує шлюзом. Старий Cisco IPsec — інший протокол, ніж AnyConnect, тому vpnc не може дістатися до сервісу лише для AnyConnect; openconnect --protocol=anyconnect — відкритий клієнт для цієї роботи.

Файл .pcf описує профіль старішого клієнта. Хост, ім'я групи й груповий пароль у ньому можна ввести вручну заново в клієнті, який говорить Cisco IPsec, хоча файл не є універсальним імпортом, і будь-який нестандартний порт або режим тунелювання зазвичай зникає під час перенесення.

Почніть із того, що шлюз насправді пропонує, потім виберіть клієнт, який говорить на цьому протоколі. Копіювання профілю з іншого сайту — це шлях, яким люди приходять до налагодження облікових даних, що ніколи не були проблемою.