криптиране на трафика за безопасност

Сигурност (криптиране) на трафика

Успоредно с развитието на технологиите за защита на интернет трафика от неоторизиран достъп и развитие на технологиите, за да прихване криптиран трафик. Прехваща и проверява некриптиран потребителски трафик за дълго време не е трудно дори и за обикновения потребител. Почти всеки знае думата "подслушване". Теоретично, сигурна SSL / TSL-прихващане с конвенционални средства е невъзможно. Но това е?

Всъщност - не съвсем. Да, кодиран трафик теоретично е невъзможно да се разчете, въпреки че отново теоретично, при много голяма нужда и желание, и този трафик може да бъде разшифрован, вземете ключа. Това обаче изисква тези разходи ресурси, които хакване значение се поддържа само, може би, на правителството или на военната ниво :)

При работа на защитена връзка (много прост пример - HTTPS) целият трафик между точките общуване в мрежата е криптирана от страната на подателя и разшифрован от страна на приемника. Кодиран трафик върви в двете посоки. За криптиране и декриптиране се нуждае от двойка ключове (асиметрично криптиране). Публичният ключ се използва за криптиране и данните се предават на получателя, както и лично - за разшифроване, той остава с подателя. По този начин, възли, между които един SSL-връзка, обмен на публични ключове. Освен това, за да се подобри ефективността формира един ключ, който се изпраща вече в шифрован вид и се използва както за криптиране и декриптиране за и от двете страни (симетрично криптиране).

За по-нататъшно "чете" всички потребителски трафик, прокси сървър заменя сертификата по своему. Т.е. той просто се свързва към самия клиент със сертификат му, а в същото време се свързва с отдалечен сървър. Клиентите идват "оставени" сертификат от зловреден сървъра, браузърът информира потребителя за опасността (такива сертификати не винаги са подписани). Потребителят е избор: да приемат удостоверението и да работите със сайта, или да откаже да го приеме, но също така и да се работи със сайта след това няма да се обърне. Понякога потребителите напълно игнорират съдържанието на сертификата и автоматично приемат каквито и да ги подава.

Ако я приеме на сертификата, фалшифициране, тогава трафикът ще отида, както следва:

клиент <= SSL-соединение => Сървър-подслушване <= SSL-соединение => целевия сървър

Т.е. междинен сървър ще получи всичките си "защитен" трафик в ясен. Трябва също да се отбележи, че удостоверението за трансфер се случи в началото на всеки HTTPS сесия.

В случай на сигурна SSH когато за първи път се свържете със сървъра на клавиша клиент домакин се съхранява и сървъра на - клиент ключа. Тези клавиши се прехвърлят между клиент-сървър само веднъж, когато за първи път се свърже. Ако в този случай SSH-движението се опита да се намеси на клиента и сървъра ще бъде отказан в микса, защото от основните несъответствия. Тъй като ключовете могат да бъдат прехвърлени между клиент и сървър чрез байпас (чрез сигурен канал или върху външната среда), този метод е сравнително безопасно съединение. Тя може да бъде блокиран само, причинявайки на потребителя да работи на открито.

Заслужава да се отбележи, че от дълго време се продават така наречените "информационни решения за сигурност бизнеса", който прихваща целия трафик, преминаващ през офиса на прокси сървър и "четат" него. Програма търси наличието на определени фрази или определени видове информация в потока от данни от уеб браузъри, програми за електронна поща, FTP-клиент, пратеници офис персонал. Освен това, тези програми са в състояние да се разграничат и правилно да се справи с различни видове информация, взаимодействие със сървъра. По-специално, те проверяват и сигурна SSL трафик от сертификати спуфинг. С развитието на една от тези системи да са срещнали почти веднага.

Но по пътя на спасението от общо наблюдение там. Чрез създадена SSH-връзка може да бъде изпратен до всяка желана трафика към SSH-сървър ще бъде в отворената форма да отида до крайната точка. Този метод се нарича SSH-тунелиране (тунелиране). Така че можете да защитите трафик минава през незащитена канал, но това има смисъл, този подход, само ако доверен сървър с повдигнати и конфигуриран за тунелиране SSH-демон. И това е съвсем лесно да се организира. SSH клиент се свързва към сървър, който е конфигуриран да подслушват всеки един порт на локалната машина. Този клиент ще предостави услугата SOCKS5 прокси-, т.е. използването му може да се конфигурира при всеки браузър, електронна поща програми, IM-ах, и т.н. Via SSH тунел пакети получават до сървъра, и от там отиват в целевия сървър. Схема се получава както следва:

[Localhost: клиент <=> прокси] <== SSH-соединение ==> сървър <=> отдалеченият сървър

Друг начин за защита на трафика - VPN-канал. По време на работа е по-лесно и по-удобно да SSH-тунелиране, но в първоначалната инсталация и конфигурация по-сложно. Основното удобство на този метод е, че не е необходимо да се регистрирате пълномощник в програмите. А някои софтуер и не поддържа прокси сървъри, VPN и следователно само костюм.

Вторият вариант - покупната VDS-сървъра (виртуални частни сървър) за всяко разпределение на Linux на борда и повдигане на VPN сървър него. VDS може да бъде български или американеца (но да не забравяме за задграничните пинг), евтин (около $ 5) и слаб или скъпо и по-мощен. VDS постави на OpenVPN-сървър и OpenVPN-клиент изкачвания на компютъра. За Windows, има дори guishnaya клиент версия.

Ако решите да използвате вариант с OpenVPN, а след това в интернет е просто инструкции стъпка по стъпка за повишаване на сървъра (Debian). Инсталиране на клиента е още по-лесно, по-специално за Windows. Марк е само един протест. Ако целия трафик, който искате да постави на виртуална частна мрежа, връзката, а след това само да зададете шлюза по подразбиране на шлюза VPN (опция пренасочване-врата към досието на клиента довереник), или само част от трафика (на някои домакини), е възможно да се определи обичайните статични маршрути до данни е домакин ( от IP; например, маршрут добавят -р 81.25.32.25 10.7.0.1).
За съединения OpenVPN обмен на ключове се среща в ръчен режим, т.е. транспортирането им от сървъра към клиента може да бъде абсолютно безопасен.

По този начин, SSH- и VPN-връзка, фактически може да гарантира безопасността на трафика, когато се движите през незащитена канал. Единственият проблем, който може да възникне в този случай - е забрана за SSL-движението по корпоративна защитна стена. Ако SSL трафик се допуска най-малко всеки един порт (обикновено по подразбиране 443), можете да имат потенциала да увеличат и SSH-Tonel и VPN-връзка, изберете подходящия демон от вашите VDS към този порт.