Виступ на семінарі:Олійник Ігор Богданович:Шифр Вернама
Презентація доповіді (університетський репозиторій)
Зміст
Опис
Для відтворення шифртексту відкритий текст об'єднується операцією «виключне АБО» з ключем(названим одноразовим блокнотом або шифроблокнотом). При цьому ключ повинен володіти трьома критично важливими властивостями:
1.Бути справді випадковим;
2.Збігатися з розміром з заданим відкритим текстом;
3.Застосовуватися тільки один раз. Шифр названий на честь телеграфіста AT&T Гільберта Вернама, що в 1917 році побудував телеграфний апарат, який виконував цю операцію автоматично - треба було тільки подати на нього стрічку з ключем. Не будучи шифрувальником, тим не менше, Вернам вірно помітив важливу властивість свого шифру - кожна стрічка повинна використовуватися тільки один раз і після цього знищуватися. Це було важко застосувати на практиці - тому апарат був перероблений на кілька зациклених стрічок з взаємно простими періодами.
Властивості
В 1949 році Клод Шеннон опублікував роботу, в якій довів абсолютну стійкість шифру Вернама. Інших шифрів з цією властивістю не існує. Це по суті означає, що шифр Вернама є найбезпечнішою криптосистемою з усіх можливих. При цьому умови, яким повинен задовольняти ключ, настільки сильні, що практичне використання шифру Вернама є важко здійсненним. Тому він використовується тільки для передачі повідомлень найвищої секретності.
Розвиток
На початку 20 ст. для передачі повідомлень все ширше і ширше використовувалися телетайпи. Тому потрібні були методи, що дозволяють шифрувати текст не до того, як він потрапляє до телеграфіста, а безпосередньо в момент передачі, і, відповідно, розшифровувати в момент прийому. Дуже хотілося доручити цю справу машині. Як виявилося, коливання струму в лінії передачі можна легко записати за допомогою осцилографа і потім перетворити у літери переданого повідомлення. Змінивши з'єднання проводів телетайпа, телеграфісти отримували повідомлення, зашифроване методом одноалфавітной заміни. Всі розуміли, що такий захист надто слабкий, але, не зумівши вигадати нічого іншого, користувалися ним до тих самих пір, поки Вернам не запропонував використовувати для кодування повідомлень особливості телетайпного коду, в якому знак, що кодується виражається у вигляді п'яти елементів. Кожен з цих елементів символізує наявність («плюс») або відсутність («мінус») електричного струму в лінії зв'язку. Наприклад, літера «А» відповідає комбінація «+ - - - -». Підготовлене до відправки повідомлення набивається на перфострічці: отвору відповідає «плюс» коду, його відсутність - «мінус». В процесі передачі металеві щупи телетайпа проходять через отвори, замикаючись у ланцюг, і посилають імпульси струму («+»). Там, де отворів немає і папір не дозволяє щупам замкнути ланцюг, імпульс не передається («-»).
Для шифрування Вернам запропонував заздалегідь готувати «гаму» - перфострічку з випадковими знаками - і потім електромеханічно складати її імпульси з імпульсами знаків відкритого тексту. Отримана сума представляла собою шифртекст. На приймальному кінці імпульси, отримані по каналу зв'язку, складалися з імпульсами тієї ж самої «гами», в результаті чого відновлювалися вихідні імпульси повідомлення. А якщо повідомлення перехоплювати, то без «гами» розшифрувати його було неможливо, противник бачив тільки нічого не значущу послідовність «плюсів» і «мінусів». Подальше вдосконалення методу, запропонованого Вернамом, належить майбутньому начальнику зв'язку військ США Джозеф Моборну, що об'єднав хаотичність «гами», на яку спирався Вернам у своїй системі «автоматичного шифрування», з використовуваним у той час у військах правилом «одноразового шифрблокнота». Ідея Моборна полягала в тому, що кожна випадкова «гама» повинна використовуватися один, і тільки один раз. При цьому для шифрування кожного знака всіх текстів, які вже передані або будуть передані в найближчому майбутньому, повинен застосовуватися абсолютно новий і такий, що не піддається передбаченню знак «гами».
Область застосування
На практиці можна один раз фізично передати носій інформації з довгим дійсно випадковим ключем, а потім по мірі необхідності пересилати повідомлення. На цьому заснована ідея шифроблокнотів: шифрувальник при особистій зустрічі забезпечується блокнотом, кожна сторінка якого містить ключ. Такий же блокнот є і у приймаючої сторони. Використані сторінки знищуються. Крім того, якщо є два незалежних канали, в кожному з яких ймовірність перехоплення низька, але відрізняється від нуля, шифр Вернама також можна застосувати: по одному каналу можна передати зашифроване повідомлення, по другому - ключ. Для того, щоб розшифрувати повідомлення, перехоплювач повинен прослуховувати обидва канали. Шифр Вернама може застосовуватися, якщо є односторонній захищений канал: ключ передається в одну сторону під захистом каналу, повідомлення в іншу сторону повідомлення захищаються ключем. Не є шифром Вернама, але близька до нього схема одноразових кодів: наприклад, кодове слово «Альфа» означає «Повертаюсь».
Технічне застосування
Очима фахівця, суть того, що відбувається така: з кінця січня (стабільна µTorrent версія 2.0 з µTP вийшла якраз 25 січня, офіційно доступна з 3 лютого) в статистичних звітах операторів зв'язку виявлено безперервне зростання UDP-трафіку і одночасне зменшення середньої величини пакетів, які істотно збільшували навантаження на мережеве устаткування. Спостереження показали, що чим сильніше завантажений канал клієнта, тим дрібніші пакети, довша черга і вище навантаження на роутерах.
У всіх випадках причиною що відбувається був названий МікроТоррент (µTorrent), з версії 1.8.1 що почав освоювати протокол обміну µTP (Micro Transport Protocol, до речі, що так не дістав схвалення IETF). І провайдерам просто повезло, що через низку обставин клієнти до версії µTorrent v2.0 не оновилися одномоментно. (У ній, за умовчанням, udp-завантаження стартує першим, а якщо не вийде, то лише тоді – по TCP). Інакше наростання проблем в мережі замість плавного носило б миттєвий характер і, можливо, відразу «повалило» до третини вітчизняних провайдерів. Останні могли б трактувати поведінку як ddos-атаки на провайдерське устаткування з відповідним недемократичним «закручуванням гайок» в аварійному порядку.
Остаточний аналіз ситуації був ускладнений тим, що у відкритому доступі повного опису протоколу, який став займати значну долю UDP трафіку, немає: цей опис застарілий і не дає повної картини, а стаття у Вікіпедії досить поверхневий описує характер проблем.
Реінженеринг дозволив не лише переконатися, що згідно з алгоритмами µTP в процесі обміну зменшується довжина пакету із зростанням завантаження каналу, але і передбачити, що для підтвердження використовуються udp-пакети квитування (з функцією, типа ACK) розміром в 2 десятки байт.
Логіка розробників протоколу і алгоритмів µTorrent може виправдовуватися тим, що вони не вважають розумними чекати TCP-ACK від доставки пакету. Адже tcp-потік формується послідовно, і якщо в стеку, наприклад, вже знаходиться 50 пакетів, але немає два, то передачу вони не здійснюватимуть, поки втрачені не прийдуть. А ось пірінгове застосування за своєю суттю якраз і не критично до строгої послідовності у вступі інформації, адже воно запрошує і збирає файли по шматочках.
І що виходить насправді? Додаток, відповідно, зменшує розмір пакету, тому що у нього зростає час між відсиланням пакету і приходом квитанції. Але зростає-то воно тому, що пакети стоять в переповненій черзі на «шейпері». І замість того що б спочатку зменшити кількість посланих, алгоритм ... далі зменшує їх розмір. В результаті, при даному агресивному алгоритмі використання udp-протоколу МікроТоррентом результуючий трафік (ємкість каналу) на клієнтові практично не міняється. Тобто вихідна мрія творців даного ПЗ – завантажити канал «під зав'язку» від цього ближче не стає. Міняється лише структура трафіку – з'являється більше дрібних пакетів, що для провайдера насправді небезпечніше чим зростання трафіку.
Давайте порахуємо: якщо в ходу пакети по 150 байт, то при швидкості 100 мегабіт операторові потрібно буде обробити в секунду ... 87 тисяч пакетів! Не всякий провайдер зможе оперативно відреагувати на виниклу проблему: замінити ті ж сервери доступа/роутери на високопродуктивних не всім по кишені. В результаті, багато провайдерів вимушено було для своїх клієнтів ввести на додаток до обмежень по Mbps, ще і по pps.
Але, навіть якщо провайдерське устаткування зможе впоратися з цим алогічним алгоритмом обміну, замість вичавлених з провайдера декількох зайвих відсотків смуги, клієнт ризикує втратити значно більше завдяки збільшеному пакетному навантаженню . на свій домашній шлюз і, можливо навіть – на свій не дуже сучасний ПК! А що він зробить, побачивши, що швидкість закачування знизилася? Правильно, без тіні сумніву звернеться в технічну підтримку і звалить свої проблеми на провайдера.
Оскільки локальна ситуація моделюється досить нескладно, я провів невеликий експеримент з наявним adsl-wifi-шлюзом, який можу запропонувати просунутим користувачам µTorrenta. Особливо вражаючим тест виглядатиме на древніх роутерах з Wifi. У моєму циклі випробувань пристрій почав «притормажувати» приблизно вже при 30-40 активних сесіях «звичайного» закачування, але при агресивній роботі по UDP (всього 5 роздач) втратило відразу майже третина смуги. Поза сумнівом, причина – в перевищення можливої кількості коректно оброблюваних пакетів за одиницю часу.
Недоліки
Щоб не попасти в безвихідь під час обвалення DDoS-штурму на системи, необхідно ретельно підготувати їх до такої ситуації:
1. Всі сервера, що мають прямий доступ в зовнішню мережу, мають бути підготовлені до простої і швидкої віддаленої. Великим плюсом буде наявність другого, адміністративного, мережевого інтерфейсу, через який можна дістати доступ до сервера в разі затурканості основного каналу.
2. ПЗ, використовуване на сервері, завжди повинно знаходитися в актуальному стані. Всі дірки - пропатчені, оновлення встановлені. Це захистить тебе від DoS-атак, експлуатуючих баги в сервісах.
3. Всі слухаючі мережеві сервіси, призначені для адміністративного використання, мають бути заховані брандмаузером від всіх, хто не повинен мати до них доступу. Тоді той, що атакує не зможе використовувати їх для проведення DoS-атаки або брутфорса.
4. На підходах до сервера (найближчому маршрутизаторі) має бути встановлена система аналізу трафіку (Netflow в допомогу), яка дозволить своєчасно дізнатися про атаку, що починається, і вчасно прийняти заходи по її запобіганню.
Додай в /etc/sysctl.conf наступні рядки:
# vi /etc/sysctl.conf
# Захист від спуфінга
net.ipv4.conf.default.rp_filter = 1
# Перевіряти TCP-з’єднання кожну хвилину. Якщо на іншій стороні - легальна машина, вона зразу відповість. Значення по замовчуванні - 2 години.
net.ipv4.tcp_keepalive_time = 60
# Повторити попитку через десять секунд
net.ipv4.tcp_keepalive_intvl = 10
# Кількість повірок перед закриттям з’єднання
net.ipv4.tcp_keepalive_probes = 5
Слід зазначити, що всі прийоми, приведені у минулому і цьому розділах, направлені на зниження ефективності DDoS-атак, що ставлять своєю метою витратити ресурси машини. Від флуда, що забиває канал сміттям, захиститися практично неможливо, і єдино правильний, але не завжди здійсненний спосіб боротьби полягає в тому, щоб "позбавити атаку сенсу". Якщо ти отримаєш в своє розпорядження дійсно широкий канал, який легко пропустить трафік невеликого ботнета, вважай, що від 90% атак твій сервер захищений. Є витонченіший спосіб захисту. Він заснований на організації розподіленої обчислювальної мережі, що включає безліч дублюючих серверів, які підключені до різних магістральних каналів. Коли обчислювальні потужності або пропускна спроможність каналу закінчуються, все нові клієнти перенаправляються на інший сервер (або ж поступово "розмазуються" по серверах за принципом round-robin). Це неймовірно дорога, але дуже стійка структура, завалити яку практично нереально.
Інше більш-менш ефективне рішення полягає в покупці дорогих хардварних систем Cisco Traffic Anomaly Detector і Cisco Guard. Працюючи у в'язці, вони можуть подавити атаку, що починається, але, як і більшість інших рішень, заснованих на вченні і аналізі станів, дають збої. Тому слід гарненько подумати перед тим, як вибивати з начальства десятки тисячі доларів на такий захист.
Здається, почалося. Що робити?
Перед безпосереднім початком атаки боти "розігріваються", поступово нарощуючи потік пакетів на машину, що атакується. Важливо зловити момент і почати активні дії. Допоможе в цьому постійне спостереження за маршрутизатором, підключеним до зовнішньої мережі (аналіз графіків Netflow). На сервері-жертві визначити початок атаки можна підручними засобами.
Наявність Syn-флуда встановлюється легко - через підрахунок числа "напіввідкритих" tcp-з'єднань:
# netstat -na | grep ":80\ " | grep Syn_rcvd
У звичайній ситуації їх не повинно бути зовсім (або дуже невелика кількість: максимум 1-3). Якщо це не так - ти атакований, терміново переходь.
З Http-флудом дещо складніше. Спершу потрібний підрахувати кількість процесів Apache і кількість з’єднань на 80-й порт (Http-флуд):
# ps aux | grep httpd | wc -l
# netstat -na | grep ":80\ " | wc –l
Значення, у декілька разів вищі за середньостатистичні, дають підстави задуматися. Далі слід проглянути список ip-адрес, з яких йдуть запити на підключення:
# netstat -na | grep ":80\ " | sort | uniq -c | sort -nr | less
Однозначно ідентифікувати DoS-атаку не можна, можна лише підтвердити свої припущення про наявність такої, якщо одна адреса повторюється в списку надто багато разів. Додатковим підтвердженням буде аналіз пакетів за допомогою tcpdump:
# tcpdump -n -i eth0 -s 0 -w output.txt dst port 80 and host ip-сервера
Показником служить великий потік одноманітних (і що не містять корисної інформації) пакетів від різних IP, направлених на один порт/сервіс (наприклад, корінь web-сервера або певний cgi-скріпт). Остаточно визначившись, починаємо банити по ip-адресах (буде значно більше ефекту, якщо ти зробиш це на маршрутизаторі):
# iptables -A INPUT -s xxx.xxx.xxx.xxx -p tcp --destination-port http -j DROP
Або відразу по підмережах:
# iptables -a INPUT -s xxx.xxx.0.0/16 -p tcp --destination-port http -j DROP
Це дасть тобі деяку фору, яку ти повинен використовувати для того, щоб звернутися до провайдеру/хостеру (з прикладеними до повідомлення балками web-сервера, ядра, брандмаузера і списком виявлених тобою ip-адрес). Більшість з них, звичайно, проігнорують це повідомлення (а хостинги з оплатою трафіку ще і порадіють - DoS-атака принесе їм прибуток) або просто відключать твій сервер. Але у будь-якому випадку це слід зробити обов'язково, – ефективний захист від DDoS можливий лише на магістральних каналах. Поодинці ти впораєшся з дрібними нападками, направленими на виснаження ресурсів сервера, але виявишся беззахисним перед більш-менш серйозним DDoS’ом.
Боротьба з DDoS в FREEBSD
Зменшуємо час чекання у відповідь пакету на запит SYN-ACK (захист від Syn-флуда):
# sysctl net.inet.tcp.msl=7500
Перетворюємо сервер на чорну діру. Так ядро не слатиме у відповідь пакети при спробі підключитися до незайнятих портів (знижує навантаження на машину під час DDoS’а на випадкові порти):
# sysctl net.inet.tcp.blackhole=2
# sysctl net.inet.udp.blackhole=1
Обмежуємо число відповідей на icmp-повідомлення 50 в секунду (захист від Icmp-флуда):
# sysctl net.inet.icmp.icmplim=50
Збільшуємо максимальну кількість підключень до сервера (захист від всіх видів DDoS):
# sysctl kern.ipc.somaxconn=32768
Включаємо Device_polling - самостійний опит мережевого драйвера ядром на високих навантаженнях (істотно знижує навантаження на систему під час DDoS'а):
• Збираємо заново ядро з опцією "options Device_polling";
• Активуємо механізм полінгу: "sysctl kern.polling.enable=1";
• Додаємо запис "kern.polling.enable=1" у /etc/sysctl.conf.
Висновки
Ботнет (англ. botnet від robot і network) — це комп'ютерна мережа, що складається з деякої кількості хостів, із запущеними ботами — автономним програмним забезпеченням.
Найчастіше бот у складі ботнета є програмою, який скрито встановлюється на комп'ютері жертви і що дозволяє зловмисникові виконувати якісь дії з використанням ресурсів зараженого комп'ютера. Зазвичай використовуються для нелегальної або несхвалюваної діяльності — розсилки спаму, перебору паролів на видаленій системі, атак на відмову в обслуговуванні.
• Kraken - 400 тисяч комп'ютерів.
• Srizbi - 315 тисяч комп'ютерів.
• Bobax - 185 тисяч комп'ютерів.
• Rustock - 150 тисяч комп'ютерів.
• Storm - 100 тисяч комп'ютерів.
• Psybot - 100 тисяч adsl-маршрутизаторів, заснованих на Linux.
• Ботнет ВПС - 22 тисячі комп'ютерів. Експериментальний ботнет, створений компанією ВПС.
1997 рік - dDoS-атака на web-сайт Microsoft. Один день мовчання.
1999 рік – "поза зоною дії" виявилися web-сайти Yahoo, CNN, ebay і ін.
Жовтень 2002 - атака на кореневі dns-сервері інтернету. На деякий час були виведені з буд 7 з 13 серверів.
Цікаву альтернативу вирішенням Cisco випускає компанія Reactive Networks (www.reactivenetworks.com). Їх продукт під назвою Floodguard є апаратним комплексом, що складається з детекторів і виконавчих модулів. Детектори, встановлені на брандмаузерах, маршрутизаторах і світчах, постійно моніторят трафік і створюють його профіль на основі таких параметрів, як об'єм пакетів, джерело, напрям, тип і так далі. В разі виникнення аномалій детектор посилає всі подробиці про подію виконавчим модулям, розташованим на маршрутизаторах в різних сегментах мережі. Отримавши повідомлення від детектора, виконавчі модулі починають діяти: вони відшукують паразитний трафік в проходящих пакетах і, в разі успіху, оповіщають про це попередні по ходу трафіку модулі і посилають їм інструкції по активації фільтрів на маршрутизаторах. В результаті, перед потоком флуд-трафіку повинен утворитися заслін, який буде швидко переміщати його в сторону істотника.
Список використаних джерел:
1. http://ru.wikipedia.org/wiki/DoS-атака
2. http://systemnews.com.ru/?mod=art&part=other&id=020
3. http://www.xakep.ru/post/49752/
