Створення VPN з використанням протоколів PPP та SSH

МІНІСТЕРСТВО ОСВІТИ І НАУКИ УКРАЇНИ

КРАСНОДОНСЬКИЙ ПРОМИСЛОВО ЕКОНОМІЧНИЙ КОЛЕДЖ

Реферат з предмету: «Інформаційна безпека»

• На тему: «Створення VPN з використанням протоколів PPP та SSH»
• Студента групи 1ОКІСМ-06
• Петренко Михайла
• Перевірила: Дрокіна Т. М.
• Краснодон
• 2010
• Одним з перших VPN рішень, призначених для самостійного втілення, було поєднання двох мереж за допомогою протоколу PPP в сесії SSH. Цей метод є загальноприйнятою практикою, проте він може здатися декілька ваговитим новачкові у використанні даних протоколів. Коли ви закінчите читання цієї глави, ви зможете створити мережу VPN на основі SSH / PPP і вручну, і за допомогою набору пропонованих нами скриптів.
• 1. Огляд поєднання "PPP-через-SSH
• Щоб краще зрозуміти реалізацію «PPP-через-SSH» давайте обговоримо ці два протоколи.
• 1.1 PPP
• PPP є абревіатурою від Point-to-Point Protocol (Протокол передачі «від точки до точки»). Цей протокол є похідним HDLC (High Level Data Link Control, Високорівневі Протокол Управління Каналом) - ще одного протоколу типу «від точки-к-точці» 2-го рівня, який використовується для здійснення управління каналом і інкапсуляції даних користувача. Найчастіше протокол PPP використовується для встановлення зв'язку між модемами по телефонній лінії, наприклад, при виклику провайдера. У більшість дистрибутивів Linux включаються такі утиліти, як wvdial або xisp, що дозволяють встановити модемне з'єднання не вдаючись у деталі команд PPP і конфігурацій, на основі яких вони працюють. Однак PPP не обмежується тільки фізичними сполуками, з'єднання за протоколом PPP можуть бути встановлені між будь-якими хостами, що мають мережевий зв'язок. Нашою метою буде встановлювати PPP-з'єднання між різними машинами через Інтернет, які ми будемо використовувати для створення VPN.
• Щоб запустити утиліту pppd, демон протоколу PPP, потрібно, щоб ядро підтримувало його. Часто PPP компілюється в модуль, запити до якого можна подавати командою lsmod. Якщо це так, він буде завантажуватися автоматично при необхідності. Ядро в більшості дистрибутивів Linux включає підтримку PPP, так що це не повинно бути проблемою.
• Більшість дистрибутивів Linux також поставляється з попередньо відкомпілювалися версіями PPP, які можна встановити. Так що вам, швидше за все, не доведеться компілювати і інсталювати pppd самостійно. Однак з причин, про які буде розказано далі, ми пропонуємо вам версію pppd 2.3.7 і вище.
• Забезпечення конфіденційності даних, що передаються ніколи не було головною метою протоколу PPP. І як наслідок, він використовує для цієї мети зовнішні методи шифрування. Ризик перехоплення даних при використанні даного протоколі зводиться до можливості підключення до лінії або захоплення одного з кінців PPP-з'єднання. Тим не менше, оскільки ми хочемо використовувати PPP для встановлення мережного з'єднання при пересиланні потоку даних через Інтернет, ми повинні провести PPP-з'єднання через незашифрований тунель.
• 1.2 SSH
• Протокол SSH (Secure Shell, безпечна оболонка) найчастіше використовується для створення безпечного оболонки для доступу до інших хостам і передачі файлів по мережі, для безпеки і аутентифікації для забезпечення конфіденційності даних. Він був розроблений як безпечна заміна Telnet і так званих r-команд (rlogin, rsh і rcp).
• У SSH підтримується потужне шифрування і просунуті методи ідентифікації користувачів, які пройшли перевірку часом. OpenSSH, реалізація протоколу SSH, створена групою розробників OpenBSD і перенесена на Linux з тієї ж OpenBSD, включається зараз за умовчанням у багато дистрибутиви Linux. SSH зараз «де факто» є безпечним методом входу в систему і передачі файлів в Unix-подібних системах.
• Існують, також, програмні реалізації SSH, виконані іншими виробниками, наприклад, ssh.com. Ми, тим не менше, віддаємо перевагу OpenSSH, оскільки він поставляється в багатьох дистрибутивах Linux, його легше конфігурувати, його версії більш сумісні між собою і в ньому підтримується і версія 1 і версія 2 протоколу SSH. Використовувані в цьому розділі налаштування припускають, що ви використовуєте OpenSSH.
• 2. Версії протоколу
• З моменту створення протоколу SSH в 1995 році, було випущено кілька різних його версій, головними з яких є версія 1.5 (також звана SSH1) і версія 2 (SSH2). OpenSSH 2.0, випущений в червні 2000 року з самого початку підтримує обидва протоколи. (Комерційні реалізації SSH також можуть підтримувати обидві версії, але тільки шляхом запуску при необхідності демона sshd для версії 1, що сильно знижує продуктивність.)
• Ці два протоколу SSH не сумісні між собою, і слід визначитися з тим, який варіант ви оберете. У протоколі SSH1 часом виникають проблеми з безпекою. Навіть зараз залишається теоретична можливість «атаки включенням» (insertion attack) проти цього протоколу, але цей ризик зводиться до мінімуму спеціальної латкою (patch) випущеної CORE-SDI ще в 1998 році. Протокол SSH1 довше використовувався і для нього існує велика база підтримки. У SSH1 підтримується тільки асиметричне шифрування RSA, запатентований в США в 2000 році. Проте, оскільки термін дії цього патенту вже минув, це більше не проблема.
• SSH2 - більш новий і багатий можливостями протокол, який наразі успішно витримує всі перевірки. Хоча встановлення з'єднання по протоколу SSH2 вимагає набагато більше часу, в останніх версіях OpenSSH цей процес істотно прискорений. SSH2 підтримує асиметричні алгоритми RSA і DSA.
• Незалежно від того, яку версію протоколу ви виберете, переконайтеся в тому, що ви використовуєте останню версію OpenSSH. Час від часу в OpenSSH виявлялися слабкі місця, такі, наприклад, як дві окремі прогалини «UseLogin» або помилка переповнення цілого числа в анти-хакерської латочки яка могла призвести до розтину користувача root. Однак розробники OpenSSH зробили набагато більше для безпеки, ніж їх колеги, які розробили SSH. OpenSSH включає в себе контрзаходи навіть на випадок таких езотеричних атак, як визначення часу натиснення клавіш (keystroke timing), коли атакуючий аналізує інтервали між пакетами, визначаючи, таким чином, наскільки близько розташовані натискаються вами клавіші і намагається за цим показником зрозуміти, що ви друкуєте .
• Ми будемо використовувати ідентифікатори (identities) SSH (асиметричні криптографічні ключі, які використовуються при аутентифікації і детально описуються нижче) для забезпечення дозволу на підключення VPN-клієнта з VPN-сервером. На жаль, формат цих ідентифікаторів в протоколі SSH1 відрізняється від SSH2. Тому, хоча OpenSSH і підтримує обидві версії протоколів, нам доведеться вирішити, який з них ми хочемо використовувати для нашої VPN. Якщо у вас є остання версія OpenSSH (а у вас вона повинна бути), ми пропонуємо використовувати SSH2. Ми докладно опишемо створення SSH-ідентифікаторів для обох протоколів, так що вибір залишається за вами.
• 3. Установка «PPP-через-SSH» вручну
• Для початку, ми покажемо вам всі компоненти даного процесу, створивши VPN між двома хостами вручну. Це створить основу для того, що ми будемо робити в описуваних пізніше скриптах і допоможе вам зрозуміти, що буде відбуватися. Це, при необхідності, допоможе і в налагодженні з'єднання.
• 3.1 Інсталяція і перевірка PPP
• По-перше, визначимо, чи встановлений PPP і на VPN-клієнта і на VPN-сервер. У Debian або інших системах, заснованих на dpkg, потрібно ввести наступне:
• root@debian$ dpkg -l ppp |grep ppp
• ii ppp 2.3.11-1.4 Point-to-Point Protocol (PPP) daemon.
• У RedHat або інших системах, заснованих на rpm, потрібно ввести наступне:
• root@redhat# rpm -q ppp
• ppp-2.3.11-4
• Переконайтеся, що встановлена версія 2.3.7 або вище, оскільки це перша версія, яка підтримує аргумент pty, необхідний для встановлення pty.
• 3.2 Включення маршрутизації IP
• Більшість дистрибутивів Linux за замовчуванням не дозволяють маршрутизацію IP-пакетів, але нам воно необхідне для маршрутизації пакетів VPN через інтерфейс PPP. Змінювати статус маршрутизації IP можна, змінюючи відповідний параметр ядра. Хоча можливо перекомпіліровать ядро і змінити значення, встановлені за замовчуванням, найбільш легкий спосіб - використовувати файлову систему / proc. Файли в / proc, насправді, файлами не є, а являють собою способи доступу та / або модифікації параметрів ядра і для того, щоб змінити їх ви повинні мати статус root. Таким чином, найпростіший спосіб включити маршрутизацію через порт - запустити наступну команду:
• root# echo 1 > /proc/sys/net/ipv4/ip_forward
• Ця команда автоматично включить маршрутизацію IP-пакетів за умовчанням у всіх інтерфейсів. При створенні VPN архітектури хост-хост це суттєво. Якщо ви бажаєте створити VPN типу мережа-мережа чи хост-мережу, вам може знадобитися включити маршрутизацію IP-пакетів тільки для тих інтерфейсів, через які і здійснюється маршрутизація. Наприклад, у випадку великої VPN-сервера вам може знадобитись здійснювати маршрутизацію через всі інтерфейси ppp (зв'язку VPN) і через інтерфейс eth1 (внутрішній інтерфейс), але не через всі інтерфейси Ethernet. Це можна зробити, використовуючи такий скрипт shell:
• #!/bin/sh
• echo “Setting up IP forwarding rules”
• echo 1 > /proc/sys/net/ipv4/ip_forward
• echo -n “/proc/sys/net/ipv4/ip_forward: “
• cat /proc/sys/net/ipv4/ip_forward
• for forwarding in /proc/sys/net/ipv4/conf/*/forwarding
• do
• echo -n “$forwarding: “;
• interface=`dirname $forwarding`
• interface=`basename $interface`
• case “$interface” in
• ppp*|eth1) # список интерфейсов
• # прохождение через которые нужно включить
• echo 1 > $forwarding
• ;;
• *) # Выключить прохождение для всех интерфейсов
• echo 0 > $forwarding
• ;;
• esac
• cat $forwarding
• done
• Обов'язково налаштуйте вираження в операторі case відповідно до ваших вимог до маршрутизації IP-пакетів. У даному випадку дозволяється маршрутизація пакетів через інтерфейс eth1 і всі ppp-інтерфейси (ppp0, ppp1, ...), а для всіх інших інтерфейсів пакети будуть відкидатися.
• 3.3 Створення користувача VPN
• Тепер необхідно створити користувача, який буде запускати команди VPN на обох кінцях з'єднання. Припустимо, ви використовуєте для обох кінців ім'я користувача sshvpn, але можна використовувати і будь-яке інше. Хоча імена користувачів не обов'язково повинні бути однакові для обох машин, це значно спрощує справу. Користувача можна створити, наприклад, таким чином:
• root# groupadd sshvpn
• root# useradd -m -d /opt/ssh-vpn -c
• “SSH VPN User” -g sshvpn sshvpn
• Програма useradd створює користувача з паролем, закритим за замовчуванням, що гарантує неможливість підключитися через нього до системи. Єдиний спосіб доступу до цих облікових записів є використання команди / bin / su для отримання прав root. Пізніше ми створимо особливий доступ до цих користувачам через протокол SSH. Домашній каталог для цього користувача традиційний - / opt / ssh-vpn. Хоча ми й могли створити домашню теку в / home, але цей користувач буде швидше використовуватися в якості програмного продукту та встановлення його в каталог / opt (або / usr і т п.) більше відповідає його призначенням. Так що надалі ми будемо використовувати каталог / opt / ssh-vpn, а ви можете використовувати будь-який.
• 3.4 Угоди про імена
• Для ясності ми назвемо ту машину, яка починає процес з'єднання VPN-клієнтом, а іншу - VPN-сервером. VPN-клієнт для з'єднання з VPN-сервером буде використовувати протокол SSH.
• Також ми повинні дати нашій VPN яке-небудь ім'я. Для прикладу, ми будемо використовувати ім'я vpn1. Оскільки наші скрипти можуть створювати більше однієї VPN, таке ім'я дозволить їх розрізняти.
• 3.5 Встановлення безпарольного SSH-з'єднання
• Наш користувач VPN на VPN-клієнта повинен мати можливість з'єднуватися з VPN-сервером без пароля. Цього можна досягти за допомогою SSH кількома різними способами. Є два стандартних методу - хостовая аутентифікація та автентифікація за ідентифікатором SSH. Інші методи, наприклад, kerberos, зазвичай вимагають значних зусиль з обслуговування і їх важко використовувати в ситуаціях, подібних до нашої.
• Хостовая аутентифікація використовує встановлення довірчих взаємин між хостами. У даному випадку будь-який користувач одного хоста (клієнт) може без пароля з'єднатися з іншим хостом (сервером). Якщо не надто вдаватися в деталі, то при цьому копія публічного хостового SSH-ключа клієнта встановлюється на сервер в / etc / ssh / ssh_known_hosts, а ім'я клієнтської машини записується в / etc / shosts.equiv. При з'єднанні клієнта з сервером, що представляється клієнтом ключ порівнюється з ключем, що зберігається у файлі. Якщо ключі співпадають, сервер робить висновок, що клієнт має право доступу та з'єднання без пароля дозволяється. Пізніше, при встановленні з'єднання, ми побачимо, як працюють хостовые ключі SSH. Якщо ви бажаєте використовувати хостовую аутентифікацію в інших проектах, зверніться за інформацією до керівництва по sshd.
• Проблема хостовой аутентифікації полягає в тому, що всім користувачам клієнта дозволяється без обмежень з'єднуватися з обліковими записами на сервері. У нашій ситуації нам потрібно, щоб з'єднання здійснював один конкретний користувач, при цьому ще потрібно накладати обмеження на команди, які користувач може подавати і повинен існувати заборона на інтерактивні з'єднання. Таким чином, хостовая аутентифікація занадто ліберальна для наших цілей.
• Ідентифікатор (identity) SSH - це просто пара з публічного і приватного ключа, що розташовується на машині - клієнта. З сервером може з'єднатися будь-який користувач, що володіє вірним ідентифікатором, і помістили свій публічний ключ в файл $ HOME / .ssh / authorized_keys на SSH-сервер. Зазвичай ідентифікатори створюються таким чином, що для їх використання потрібна ідентифікаційна фраза (passphrase, багатослівний варіант пароль).
• Таким чином, модель, що використовує ідентифікатор SSH, дозволить користувачеві VPN на машині-клієнті з'єднатися з сервером без пароля, і при цьому жодні інші з'єднання з сервером дозволять не будуть. Пізніше ми побачимо, що в ідентифікатор SSH можна ввести обмеження та іншими вигідними способами.
• 3.6 Створення ідентифікатора SSH
• Для початку потрібно створити ідентифікатор SSH на VPN-клієнта. Станом користувачем sshvpn і створимо каталог. Ssh:
• root@falcons-client# su - sshvpn
• sshv
• pn@falcons-client$ pwd
• /opt/ssh-vpn
• sshvpn@client$ mkdir .ssh
• sshvpn@client$ chmod 700 .ssh
• Якщо ви хочете використовувати протокол SSH1, для створення безпарольного ідентифікатора SSH в ~ / .ssh / identity використовуйте наступні команди:
• sshvpn @ falcons-client $ ssh-keygen-t rsa1-N''
• Generating public / private rsa1 key pair.
• En
• ter file in which to save the key (/ opt / ssh-vpn / .ssh / identity):
• Your identification has been saved in / opt-ssh-vpn/.ssh/identity.
• Your public key has been saved in / opt / ssh-vpn / .ssh / identity.pub.
• The key fingerprint is:
• a8: 28:08:2 b: 3c: b3: 52:13:26: f0: ac: 5e: 43: df: 20: fb sshvpn @ client
• 4. Перевірка безпарольного з'єднання
• Тепер спробуємо поєднати клієнта з сервером ще раз. Якщо все було встановлено нормально, ви повинні отримати можливість з'єднатися без введення пароля і без питань про хостовом ключі:
• sshvpn@falcons-client$ ssh server `echo `hostname`'
• server.example.com
• sshvpn@falcons-client$
• Якщо з'єднатися без введення пароля не вдалося, перевірте наступне:
• Права доступу. Протокол OpenSSH дуже чутливий до прав доступу. Переконайтеся в тому, ~ sshvpn і ~ sshvpn / .ssh мають режим 700, а файл authorized_keys (2) - 600.
• Несумісності протоколів. Переконайтеся, що і клієнт і сервер підтримують обраний вами протокол SSH. Також, OpenSSH за замовчуванням може використовувати невідповідний протокол. Примусово виставити протокол можна опціями командного рядка ssh -1 або ssh -2.
• Якщо причина виявилася не в цьому, перевірте протокол syslog на сервері (зазвичай знаходиться в / var / log / messages) і активуйте параметр командного рядка ssh-v для налагодження. Якщо проблема як і раніше виникає, перегляньте сторінку man ssh (1), сторінку SSH FAQ (Frequently Asked Question, часто ставляться) на сайті http://www.employees.org/ ~ satch / ssh / faq, або попросіть допомоги в списку розсилки SSH. Інформацію про цей список можна побачити на сторінці FAQ.
• 4.1 Установка Sudo
• Програма pppd, що використовується для встановлення з'єднання між нашими VPN-хостами, може бути запущена тільки користувачем root. Оскільки ми хочемо запускати наші VPN-скрипти на обох кінцях з'єднання від імені фіктивного користувача, нам потрібно знайти спосіб отримати привілеї root для запуску цієї програми.
• Sudo - універсальна програма, що дозволяє користувачам запускати обмежений набір команд від імені користувача root. Ми створимо дуже простий набір правил, який дозволить нам запустити команду pppd.
• Програму Sudo можна знайти на сайті www.courtesan.com / sudo / .Ее також включають в багато дистрибутиви Linux, так що вам може і не потрібно компілювати її самостійно.
• Після установки Sudo, запустіть команду visudo для редагування файлу / etc / sudoers. Не намагайтеся редагувати цей файл уручну (не користуючись visudo), оскільки ви можете пошкодити його! У кінець файлу додайте наступні рядки:
• Cmnd_Alias VPNs=/usr/bin/pppd
• sshvpn ALL=NOPASSWD: VPN
• Змініть рядок шляху / usr / bin / pppd, якщо стан pppd у вашій системі інше. Також, у другому рядку замініть sshvpn на ім'я створеного вами фіктивного користувача SSH VPN, якщо ви вибрали інше ніж ми. Після завершення збережіть зміни і вийдіть з редактора.
• Отримані рядка коду дозволять користувачеві sshvpn запускати команду / usr / bin / pppd з будь-якими необхідними аргументами. Через вказівки елемента NOPASSWD користувачеві не потрібно вводити свій пароль перед отриманням доступу до програм. Оскільки нам потрібно, щоб команди виконувалися за допомогою скрипта, тобто автоматично, ми не можемо вводити пароль.
• Щоб провести швидке тестування, просто введіть такі рядки на клієнтської машині і на сервері:
• root@machine# su - sshvpn
• sshvpn@machine$ sudo /usr/sbin/pppd noauth
• ~y}#A!}!}!} }4}”}&} } } } }%} (продолжается такая же абракадабра....)
• Забавні символи представляють собою результат спроби pppd встановити з'єднання з вашим терміналом. Перейдіть до іншого вікна і виконайте команду killall-HUP pppd для зупинки процесу pppd.
• Якщо файл sudoers змінений невірно, від вас буде потрібно введення пароля. Перевірте синтаксис цього файлу. І знову обов'язково використовуйте програму visudo, і не редагуйте цей файл вручну.
• 4.2 Обхід PPP-аутентифікації
• Протокол PPP зазвичай використовується для створення мережного з'єднання між двома хостами по модему і майже завжди вимагає, щоб перед встановленням з'єднання користувач проходив аутентифікацію. Ми обговоримо, як можна включити PPP-аутентифікацію пізніше в цьому ж розділі, коли будемо пропонувати готовий до використання VPN-скрипт. Проте зараз нам потрібно прибрати цю можливість і дозволити виконувати аутентифікацію протоколу SSH. Отже зараз ми не будемо використовувати такі аргументи - require-pap, require-chap, name, remotename і user.
• 4.3 Встановлення PPP з'єднання вручну
• Тепер у нас є все що потрібно для з'єднання двох мереж:
• Можливість поєднати клієнт з сервером без введення пароля за допомогою ідентифікаторів SSH.
• Можливість запустити pppd від імені користувача root за допомогою sudo.
• Давайте запустимо pppd на клієнті, з'єднаємося з віддаленим сервером і запустимо pppd там.
• sshvpn@falcons-client$ sudo /usr/sbin/pppd updetach noauth \
• pty “sudo -u sshvpn ssh -t -t server.example.com \
• sudo pppd noauth 192.168.254.254:192.168.254.253”
• Using interface ppp0
• Connect: ppp0 <--> /dev/pts/2
• Deflate (15) compression enabled
• local IP address 192.168.254.253
• remote IP address 192.168.254.254
• Тепер давайте детально розглянемо цю жахливу командний рядок:
• sudo /usr/sbin/pppd updetach noauth
• Запуск pppd від імені root через sudo. Від терміналу не відключали, що дозволяє переглянути інформацію про IP-адресах. Аутентифікація не потрібно.
• pty “sudo -u sshvpn ssh -t -t server.example.com \
• Аргумент команди pty визначає команду, яка запускає для з'єднання з віддаленою PPP-службою. Оскільки PPP запущено від імені користувача root (через sudo), команда ssh буде також запущено від імені root. Це неправильно, оскільки в такому випадку ми опинимося в залежності від вмісту каталогу / root / .ssh користувача root. Тому нам треба запустити ssh від імені sshvpn за допомогою команди sudo-u sshvpn ssh .... Аргументи-t і-t змушують виділити на сервері pty (псевдотермінал) для даного з'єднання, що потрібно для pppd. server.example.com - це, очевидно, ім'я сервера.
• sudo pppd noauth 192.168.254.254:192.168.254.253”
• Оскільки ми з'єдналися з VPN-сервером від імені користувача sshvpn, для запуску pppd від імені root нам потрібно використовувати sudo. Аргумент noauth дозволяє використовувати PPP без будь-якої аутентифікації. Два IP-адреси показують локальний і віддалений адреса для даного PPP-з'єднання. Потрібно вибрати мережі, які точно не використовуються ніякими машинами. Маска мережі для даного з'єднання - 255.255.255.255, що означає що можна створювати для зв'язків PPP скільки завгодно окремих пар IP-адрес, якщо при цьому не дублювати вже використовуються.
• 5. Підвищення безпеки VPN
• Для підвищення безпеки вашої VPN ви можете зробити певні кроки, зокрема, в області аутентифікації. Якщо ви правильно слідували процедурою, особливо, в плані безпеки генерації та установки ідентифікатора SSH на клієнтську машину і перевірки хостового SSH-ключа сервера, ці поліпшення не є необхідними з точки зору безпеки VPN. Однак додавання деяких елементів управління не зашкодить. Ми пропонуємо для параноїків такі обмеження.
• Тепер, коли ми довели, що можемо створити VPN, можемо додати ще безпеки, зажадавши аутентифікацію. Протокол PPP включає в себе методи аутентифікації за допомогою PAP (Password Authentication Protocol) - протоколу аутентифікації пароля, і CHAP (Challenge Handshake Authentication Protocol) - протоколу аутентифікації з попереднім узгодженням дзвінка.
• Аутентифікація PAP відкрито посилає секретні дані (пароль) по з'єднанню, CHAP надходить інакше. У цьому випадку посилається змінений пароль і виклик від хоста. Оскільки наше PPP-з'єднання встановлюється через зашифроване SSH-з'єднання, в даному випадку немає причин віддавати перевагу аутентифікацію CHAP аутентифікації PAP.
• Щоб бути абсолютно впевненим у тому, що з'єднання встановлено саме з тією машиною, з якої потрібно, можна зробити так, щоб демон PPP вимагав аутентифікації на обох кінцях з'єднання. Звичайно, це вже трохи занадто, оскільки перевірка обох кінцевих точок здійснюється за допомогою SSH: клієнтська машина аутентифікує - за ідентифікатором SSH, а сервер - по хостовому ключа SSH.
• І все ж, якщо ви хочете встановити на вашому з'єднанні PAP або CHAP-аутентифікацію, потрібно буде відредагувати відповідно файл / etc / ppp / pap-secrets або / etc / ppp / chap-secrets. Правильним вибором аргументів name, remotename і user команди pppd ми можемо покращити читаність файлів / etc / ppp / (pap-secrets chapsecrets).
• Наприклад, на клієнтської машині будемо використовувати такі аргументи pppd:
• debug require-pap show-password name vpn1-client \
• user vpn1-client remotename vpn1-server
• На сервері використовуємо такі аргументи:
• debug require-pap show-password name vpn1-server \
• user vpn1-server remotename vpn1-client
• При використанні CHAP замість PAP, все робиться аналогічним чином, за винятком того, що використовується файл / etc / ppp / chap-secrets, у командному рядку команди pppd вказується require-chap і шифрування пароля за допомогою crypt () не проводиться. Аутентифікація CHAP через свою архітектури не може обробляти зашифровані паролі.
• У представленому прикладі аутентифікація потрібно і на клієнтської машині і на сервері. Можна проводити аутентифікацію тільки для одного з кінців з'єднання. Просто замініть require-(pap, chap) на noauth на тому кінці, на якого аутентифікації бути не повинно.
• 5.1 Запуск власного демона ssh на VPN-сервер
• Ви цілком можете використовувати ваш вже існуючий демон ssh на VPN сервер для SSH-з'єднань всередині VPN. Однак значення конфігурацій за замовчуванням для SSH занадто ліберальні для наших цілей, а здорова параноя ніколи не завадить, тому можна запустити на VPN-клієнта окремий демон.
• Все що нам потрібно - це створити другий файл sshd_config, в якому вказати інший, ніж за замовчуванням (22) порт і обмежувальні опції. Користувач sshvpn на клієнтської машині зв'яжеться тепер з цим демоном. Ось новий файл sshd-config, який ми розмістимо в / opt / ssh-vpn / etc:
• Port 9876
• PidFile /var/run/sshd_vpn.pid
• HostKey /etc/ssh/ssh_host_key
• HostKey /etc/ssh/ssh_host_rsa_key
• HostKey /etc/ssh/ssh_host_dsa_key
• ServerKeyBits 768
• LoginGraceTime 600
• KeyRegenerationInterval 3600
• SyslogFacility AUTH
• LogLevel INFO
• RSAAuthentication yes
• AllowUsers sshvpn
• # Restrictive settings
• #
• IgnoreRhosts yes
• IgnoreUserKnownHosts yes
• PermitRootLogin no
• StrictModes yes
• PasswordAuthentication no
• PermitEmptyPasswords no
• ChallengeResponseAuthentication no
• RhostsAuthentication no
• RhostsRSAAuthentication no
• X11Forwarding no
• PrintMotd no
• KeepAlive yes
• При такій конфігурації підключення дозволяється тільки користувачеві sshvpn, ніякі методи аутентифікації крім ідентифікаторів SSH не використовуються, а номер порту встановлюється в 9876. Можна використовувати списки контролю доступу (ACL) ядра з командами ipchains / iptables, якщо хочете обмежити доступ до цього порту. При використанні іншого порту ви отримуєте можливість використовувати з демоном ssh для доступу до VPN інші ACL, ніж для стандартного доступу по протоколу SSH через порт 22.
• Запустити цей демон можна просто за допомогою команди / usr / sbin / sshd-f / opt / sshvpn / etc / sshd_config. Також, для запуску цього демона може знадобитися змінити стартовий скрипт для sshd у файлі / etc / init.d. Будь-який VPN-клієнт, який захоче з'єднатися з цим SSH-демоном, повинен буде вказати новий порт за допомогою аргументу команди ssh-p portnum