Я знаю, що люди можуть змінювати заголовки IP та змінювати IP-адресу джерела, але мережеві пристрої повинні бути простими для виявлення цих повідомлень. Якщо їх немає, чому це так важко? Це додає занадто багато накладних витрат?
Відповіді:
Я знаю, що люди можуть змінювати заголовки IP та змінювати IP-адресу джерела, але мережеві пристрої повинні бути простими для виявлення цих повідомлень.
Підроблені IP-адреси джерел у заголовках можуть бути виявлені та заблоковані в комерційній передачі мережі; інші підроблені заголовки IPv4 можуть бути дещо складнішими для визначення. Більшість людей посилаються на функцію виявлення підроблених IP-адрес джерела як "Unicast Reverse Pathing Forward ", яка скорочується uRPF ; uRPF визначений в RFC 3704 і вважається найкращою практикою в Інтернеті . uRPF слід застосовувати на першому маршрутизаторі з обладнання для обслуговування клієнтів або на крайовому маршрутизаторі в корпоративній мережі.
Якщо їх немає, чому це так важко? Це додає занадто багато накладних витрат?
Поки маршрутизатор не є маршрутизатором, який базується на процесорі, не існує штрафу за продуктивність. У багатьох маршрутизаторах / комутаторах, що використовуються провайдерами, ця функція вбудована в ASIC апаратно; як правило, не існує величезного штрафу за його ввімкнення. Іноді трапляються конфлікти між властивостями, але знову ж таки це не велика справа в більшості випадків.
Політика та компетенція інженерного / оперативного персоналу провайдерів різняться, і багато провайдерів Інтернет-послуг (особливо в менших країнах) настільки зайняті тим, щоб все "працювало", що у них немає циклів, щоб зробити так, щоб "працювали добре".
Для запобігання зміні IP-адреси джерела потрібні або списки доступу (ACL), або одноадресна фільтрація зворотного шляху (uRPF).
Не приходьте безкоштовно. uRPF, як правило, вимагає додаткового пошуку або більш складного одиночного пошуку, тому він навіть може зменшити наполовину продуктивність пошуку на деяких платформах. ACL сповільнить пошук і використовувати пам'ять.
uRPF не потребує обслуговування, ви просто налаштуєте його один раз і забудете. ACL потребує системи, яка знає, які адреси стоять за інтерфейсом і гарантує, що ACL залишається в курсі сучасних даних.
ACL, більш широко підтримуваний, ніж uRPF, uRPF є порівняно рідкісною ознакою в пристроях рівня комутаторів L3. У «справжніх» маршрутизаторах зазвичай доступні обидві функції.
Навіть якщо доступні обидві функції, конфігурація uRPF в неправильному місці може зламати мережу, не розуміючи конкретні обмеження для платформи ACL, це може призвести до відключень.
Зазвичай ви самі не отримуєте користі у запобіганні підробці адрес джерела, користь здебільшого має Інтернет. Ви несете ненульовий ризик, намагаючись це зробити, тому що ви можете зламати речі. І ваші клієнти не отримають ніякої вигоди, ніхто не заплатить вам більше за їх реалізацію. Тож винагорода низька.
Відповідальний постачальник послуг це робить, тому що це правильно робити, але нереально сподіватися, що ми отримаємо антивідкриття у відносно значній частині розгорнутих пристроїв доступу. Набагато реалістичнішою є мета, якщо ми робимо ACL в IP-транзитних з'єднаннях, оскільки там є лише близько 6000 або близько тупих AS номерів.
Чому це навіть питання, це через атаки відображення UDP, які можна виправити за допомогою таких протоколів, як QUIC та MinimaLT, які забезпечують, що відбиття не має жодних вигод, оскільки вхідний запит гарантовано більший, ніж вихідний відповідь, тому підробляння втрачає свою користь.
Останнім часом знову стало досить популярним використання відображення UDP як DDoS-атаки. У споживчих CPE-пристроях є багато широко відкритих серверів DNS, про які споживачі не знають, тому ці споживачі страждають, коли їх домашній зв’язок перевантажений, оскільки він використовується для відображення атаки. І це також простий спосіб отримати значне посилення, невеликий запит із десятків байтів може дати великий відповідь у понад тисячу байтів. Були відбиті DDoS-атаки, які мають кілька сотень гігабітів на секунду, і менші - щодня, лише в неділю вночі ми перенесли атаку 43 Гбіт / с до одного з наших клієнтів.
Фільтрація адрес джерела нетривіальна в реальному світі, оскільки маршрутизація в Інтернеті несиметрична, тому в принципі нам потрібна освідчена здогадка, чи може пакет з цього джерела з'являтися на цьому вхідному інтерфейсі.
Для цього немає простої формули, тому що для кожного правила, яке працює майже у всіх випадках, також існує випадок використання, який має сенс для бізнесу, який би порушився тоді.
Фільтрація зворотного шляху чудово працює на крайових маршрутизаторах, де чітке визначення поняття "всередині" та "зовні" - ви не дозволяєте стороннім особам використовувати "всередині" адреси та навпаки. Це ускладнюється, як тільки я починаю використовувати декілька крайових маршрутизаторів для надмірності.
Для магістральних маршрутизаторів єдиний спосіб фільтрації зворотного шляху може бути реалізований - це дозволяти вхідним пакетам, коли одноранговий оголошує робочий маршрут (незалежно від того, чи буде це нашим уподобанням). Це було б надзвичайно тривалим пошуком, який легко обійти і порушує випадок використання, коли я навмисно купую транзит, але не оголошую свій префікс за цим посиланням.