Захист каналів зв’язку

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

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

Проте незалежно від того чи у вас є пряма лінія чи VLAN все ж залишається імовірність появи, так званого man-in-the-middle — третього учасника, якому стає доступний ваш трафік. До двопровідної (DSL) лінії можна під’єднатися просто двома «крокодилами», а в ethernet чи оптичну лінію можна зробити врізку і поставити концентратор (не комутатор!!!). Спецзв’язок від таких дій захищають поміщаючи кабелі в герметичну трубу, в яку накачують під тиском повітря і ставлять датчик: впав тиск — хтось пошкодив трубу — за шкірку і в відповідну службу... Але таку систему може собі дозволити тільки держава і великі корпорації.

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

Висновок — потрібен ще один рівень захисту.

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

Отже захистити лінію ззовні ми не можемо, тому очевидний вихід — шифрувати дані і максимально параноїдально відноситися до трафіку з зовнішньої лінії чи VLAN'у.

Підходи до технічної сторони цього рішення є два:

Перший — на випадок, якщо до вас може прийти якась перевірка, котра захоче паперового підтвердження вашої захищеності. В цьому випадку вам слід придбати обладнання з підтримкою шифрованих VPN-тунелів, але обов’язково таке, на яке ви зможете отримати від виробника чи дистрибютера завірену копію сертифіката. Є заявлений функціонал шифрування, є сертифікат, де держава визнала цей пристрій «відповідним» — є щастя для перевіряючих. В найпростішому випадку ви обійдетеся стобаксовим DLink DIR-330 (він вам буде потрібен з обидвох сторін, тому готуйтеся викласти двісті «зелених» за кожну лінію), якщо конфігурація мережі складніша — доведеться розрулювати за допомогою 250-баксового DFL-210 (якщо ще знайдете, бо він нещодавно знятий з виробництва, а якщо не знайдете — готуйте 350 у.йо.за його наступника — DFL-260). Якщо ліній декілька, то можливо в центральному офісі простіше буде поставити шестипортовий DFL-1600 за 1800 «зелених».

Можна вибрати замість DLink'a будь-яку іншу фірму, але по-перше — вони найдешевші, по друге — в них по Україні є регіональні представництва, де точно можна отримати необхідні папери, а як з іншими виробниками домовлятися я не знаю.

Другий підхід задовільнить вас, якщо дотримуватися формальностей не потрібно.

Елегантний варіант — придбати роутери Mikrotik RB/750 за $50, по одному на кожну точку (кількість ліній + один в центрі) і налаштувати на них OpenVPN або IPSec тунелі. Продається цей девайс переважно через internet-магазини, сертифікація його в Україні — діло темне, але ми ж «забили» на формальності...

Дешевий варіант — взяти старі списані комп’ютери (якщо немає, то за 20-30 баксів старенький Celeron можна по оголошеннях знайти), докупити до них за 5 баксів додаткову мережну картку, поставити щось типу Damn Small Linux i налаштувати OpenVPN тунелі та фаєрвол.

На налаштуваннях зупинюся детальніше:

Сервер. Тут для рулювання VLAN'ами потрібна буде утиліта vconfig, а для швидкої, але параноїдальної настройки — утиліти brctl та tunctl. Ну і сам openvpn, звичайно. Інтерфейс eth0 під’єднуємо до локалки, eth1, відповідно, до провайдера.

Вмикаємо картки:
ip link set lo up
ip link set eth0 up
ip link set eth1 up

створюємо відповідну кількість віртуальних тунельних пристроїв:
tunctl
tunctl
.........

вмикаємо їх:
ip link set tap0 up
ip link set tap1 up
........

створюємо та вмикаємо «міст» (в вінді воно теж називається «Падключєніє тіпа мост», але тут воно трохи логічніше виглядає):
brctl addbr br0
ip link set br0 up

і додаємо в нього учасників:
brctl addif br0 eth0
brctl addif br0 tap0
brctl addif br0 tap1
........

в житті так не буде, але для простоти вважатимемо, що провайдер дав нам VLAN'и з номерами 100, 101 і т.д. Розділимо їх з загального потоку:
vconfig set_name_type VLAN_PLUS_VID

vconfig add eth1 100
ip link set vlan0100 up
ip addr add 192.168.100.1/30 dev vlan0100

vconfig add eth1 101
ip link set vlan0101 up
ip addr add 192.168.101.1/30 dev vlan0101

.........

Стрічка з set_name_type потрібна для певності, що імена VLAN-адаптерів будуть вигляду vlanXXXX, бо є й інші варіанти і я не впевнений що від версії до версії vconfig не міняв налаштувань за замовчуванням. Маска мережі 30 дозволяє мати в такій мережі лише два комп’ютери, що додатково відсіче нам потенційні спроби третього підключення.
Залишилося запустити openvpn-сервери — по одному на кожне з’єднання. Можна один для всіх, але так конфігурація буде простіша:
openvpn --daemon --config /etc/openvpn/divizion0.ovpn
openvpn --daemon --config /etc/openvpn/divizion1.ovpn
.........

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

Все це, звісно ж, не набираєте кожен раз руками, а записуєте в файл, даєте права на виконання і додаєте його до скриптів завантаження.

Наступний момент — треба створити ключ(і) шифрування та конфігурації openvpn'a. Думаю одного ключа на всі підрозділи буде достатньо:
openvpn --genkey --secret /etc/openvpn/static.key
і конфігурація для першого підрозділу (файл /etc/openvpvn/divizion0.ovpn) виглядатиме так:
port 1100
dev tap0
secret /etc/openvpn/static.key

для другого і наступних — робимо відповідні зміни в перших двох стрічках.

Якщо мучить параноя, то можна і ключів нагенерувати кожен на своє підключення і фаєрволом обмежити прив’язку VLAN'a до openvpn'a. Тоді в конфігураціях openvpn'a буде відрізнятися і третя стрічка, а до нашого скрипта слід додати правила фільтрування пакетів:
iptables -P INPUT DROP
iptables -A INPUT -i vlan0100 -p udp --dport 1100 -j ACCEPT
iptables -A INPUT -i vlan0101 -p udp --dport 1101 -j ACCEPT
......

Вуаля! Наш сервер приймає лише з’єдання openvpn (причому на нестандартних портах, що теж додає атакуючим роботи), нічого не маршрутизує (тому всі спроби використати його як шлюз завідомо марні), от тільки і віддалено адмініструвати його не получиться (а дуже треба? сумніваюся... про нього взагалі можна надовго забути після настройки.)

Залишилися клієнти. Їх можна налаштувати точно за тією ж схемою і тоді ви отримаєте одну велику мережу, так ніби всі комп’ютери ввімкнені в один комутатор. Це добре з точки зору простоти адміністрування, але погано, якщо згадати, що весь бродкаст та мультикаст (пакети без чітко вказаного адресата) буде загаджувати канали зв’язку, які зазвичай і так не дуже широкі. Тому краще віддалені точки налаштувати як маршрутизатори — в цьому режимі такий паразитний трафік відсікається. Також немає змісту працювати з мітками VLAN'a на віддаленій стороні, бо там він (VLAN) лише один, тому доцільно попросити провайдера знімати цю мітку на його обладнанні, щоб ми отримували вже «чистий» трафік.

З цими припущеннями скрипт ввімкнення мережі виглядатиме так (eth0 i eth1 підключаємо так як і на сервері):
ip link set lo up
ip link set eth0 up
ip link set eth1 up

tunctl #<-з цієї сторони лише раз
ip link set tap0 up
ip addr add {якась адреса з вашої мережі в центральному офісі}

ip addr add 192.168.200.1/24 dev eth0 #<- робимо окрему адресацію для підрозділу
ip addr add 192.168.100.2/30 dev eth1 #<- друга сторона VLAN'a

openvpn --daemon --config /etc/openvpn/client.ovpn

iptables -A FORWARD -o eth1 -j DROP #<- відсікаємо спроби маршрутизації в
# openvpn'івську міні-мережу
iptables -A FORWARD -i eth1 -j DROP #<- і з неї також

echo 1 > /proc/sys/net/ipv4/ip_forward #<- і тільки тепер вмикаємо маршрутизацію

В залежності від конфігурації можна налаштовувати NAT, можна додати ще одну картку і налаштувати окремий канал інтернету, але це все не стосується теми. А стосується її ще конфігурація openvpn-клієнта:
dev tap0
remote 192.168.100.1 1100
secret /etc/openvpn/static.key

тут static.key (або, якщо ви вирішили генерувати по ключу на кожна підключення, то відповідний йому) генерувати не потрібно, а слід переписати з сервера. І інтерфейс tap0 від клієнта до клієнта міняти назву не буде.

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




 

Працює на AutoGenCMS 0.2.6

А чому це всі вирішили, що в сайта має бути шапка?