Чи є IP-адреси "тривіальними для підробки"?

Я читав деякі нотатки про нову загальнодоступну службу DNS Google :

• Переваги від продуктивності
• Переваги безпеки

Я помітив у розділі безпеки цей параграф:

До тих пір, поки загальносистемне рішення вразливих місць DNS не буде впроваджено універсально, як-от протокол DNSSEC2, відкриті DNS-рішення повинні самостійно вживати певних заходів для зменшення відомих загроз. Запропоновано багато методик; див. IETF RFC 4542: Заходи для підвищення DNS більш стійких щодо підроблених відповідей для огляду більшості з них. У Google Public DNS ми застосували та рекомендуємо такі підходи:

• Перевиконання машинних ресурсів для захисту від прямих атак DoS на самих розділювачів . Оскільки IP-адреси є тривіальними для зловмисників, які підробляють, неможливо блокувати запити на основі IP-адреси або підмережі; єдиний ефективний спосіб впоратися з такими атаками - це просто поглинати навантаження.

Це гнітюче усвідомлення; навіть на стеку Overflow / Server Fault / Super User, ми часто використовуємо IP-адреси як основу для заборон та блоків усіх типів.

Думати, що "талановитий" зловмисник може тривіально використовувати будь-яку IP-адресу, яку вони хочуть, і синтезувати стільки унікальних підроблених IP-адрес, скільки хоче, насправді страшно!

Тож моє питання:

• Чи справді це , що легко зловмисникові підробити IP - адреса в дикій природі?
• Якщо так, то які пом'якшення можливі?

Як зазначають багато інших, IP-заголовки є тривіальними підробками, доки людина не піклується про отримання відповіді. Ось чому це в основному спостерігається з UDP, оскільки TCP вимагає тристороннього рукостискання. Одним з помітних винятків є потоп SYN , який використовує TCP та намагається пов'язати ресурси на приймаючому хості; знову ж таки, оскільки відповіді відкидаються, адреса джерела не має значення.

Особливо неприємним побічним ефектом здатності зловмисників підробляти адреси джерел є атака зворотного розбиття . Існує відмінне опис тут , але коротко, це зворотне традиційної DDoS атаки:

1. Отримайте контроль над ботнетом.
2. Налаштуйте всі свої вузли для використання однієї і тієї ж вихідної IP-адреси для шкідливих пакетів. Ця IP-адреса стане вашою можливою жертвою.
3. Відправляйте пакети з усіх ваших контрольованих вузлів на різні адреси в Інтернеті, орієнтуючись на порти, які, як правило, не відкриті, або підключення до дійсних портів (TCP / 80), які заявляють, що є частиною вже існуючої транзакції.

У будь-якому з випадків, зазначених у (3), багато хостів відповість ICMP недоступним або скиданням TCP, орієнтованим на адресу джерела шкідливого пакету . Зараз у зловмисника потенційно є тисячі безкомпромісних машин у мережі, що здійснюють DDoS-атаку на обрану жертву, все за допомогою використання IP-адреси підробленого джерела.

Що стосується пом'якшення, цей ризик дійсно є таким, до якого можуть звертатися лише Інтернет-провайдери (особливо провайдери, що надають доступ клієнтам, а не транзит). Є два основні методи цього:

1. Фільтрація поглиблення - забезпечення пакетів, що надходять у вашу мережу, виходить із діапазонів адрес, що знаходяться на іншій стороні вхідного інтерфейсу. Багато постачальників маршрутизаторів реалізують такі функції, як зворотне переадресація маршрутів одноадресної передачі , які використовують таблиці маршрутизації та переадресації маршрутизатора, щоб перевірити, що наступним стрибком вихідної адреси вхідного пакету є вхідний інтерфейс. Це найкраще виконувати на першому шарі 3 хопу в мережі (тобто ваш шлюз за замовчуванням.)

2. Ефірна фільтрація - гарантує, що пакети, що залишають вашу мережу, лише джерелом з діапазонів адрес, якими ви володієте. Це природне доповнення до фільтрування проникнення, і по суті є частиною того, щоб бути «добрим сусідом»; гарантуючи, що навіть якщо ваша мережа порушена зловмисним трафіком, цей трафік не буде переадресований на мережі, з якими ви робитесь.

Обидві ці методи є найбільш ефективними і легко реалізуються, коли це робиться в мережах "край" або "доступ", де клієнти взаємодіють з провайдером. Здійснення фільтрування входу / виходу над шаром доступу стає складніше через складність кількох шляхів та асиметричного маршрутизації.

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

Чи справді так легко зловмисникові підробити IP-адресу в дикій природі?

Звичайно, якщо мені не байдуже насправді отримувати відповіді, я можу дуже легко надсилати пакети, використовуючи будь-яку адресу джерела, яка мені подобається. Оскільки у багатьох провайдерів дійсно немає хороших правил виходу, все, що я підроблю, як правило, буде доставлено.

Якщо нападнику дійсно потрібна двостороння комунікація, це стає дуже важко. Якщо їм потрібна двостороння комунікація, це, як правило, простіше просто скористатися проксі-сервером. Що дуже просто налаштувати, якщо ви знаєте, що робите.

Заборона людей за IP-адресою помітно ефективна для SF / SO / SU, оскільки сайт використовує http / https, що вимагає двостороннього спілкування.

Невелике підтвердження концепції відповіді Зордече (з ubuntu):

$ sudo apt-get install hping3
$ sudo hping3 -1 --spoof 11.10.10.20 www.google.com
HPING www.google.com (eth0 64.233.169.105): icmp mode set, 28 headers + 0 data bytes

Потім в іншій консолі:

$ sudo tcpdump -i eth0 'icmp'
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth0, link-type EN10MB (Ethernet), capture size 96 bytes
13:30:19.439737 IP 11.10.10.20 > yo-in-f105.1e100.net: ICMP echo request, id 31297, seq 0, length 8

Так що, банально, але тоді ви не отримаєте відповідей, як згадувалося раніше, якщо ви не маєте доступу до 11.10.10.20 або не маєте снігуру десь між www.google.com та 11.10.10.20 (І це повинно бути прямо навпроти будь-якого кінця, оскільки ви не можете передбачити маршрут пакетів). Крім того, шлюз шпуфера (ISP) може не випустити цей пакет у двері, якщо у них буде якась перевірка ip і побачити, що джерело погано пахне.

IP-адреси легко підробляти для однонаправленого трафіку UDP . Для пакетів TCP ви можете лише підробити, щоб отримати напіввідкриті TCP-з'єднання з SYN-пакетами. Це також основа свого роду DOS-атаки. Але ви не можете підробити HTTP-з'єднання із підробленою адресою (наприклад, якщо ви фільтруєте сеанси, щоб використовувати ту саму IP-адресу). Хоча так, ви можете підробляти ІР-адресу в пакетах, це корисно лише для певних видів відмови в сервісних атаках.

Стаття GOOG прямо обговорювала DNS. DNS використовує як UDP, так і TCP пакети. UDP можна підробити, але не TCP. TCP вимагає тривимірного рукостискання . Якщо IP-адреса для пакета TCP підроблена, комп'ютер, що підробляє, не отримає відповіді, і з'єднання не вдасться. UDP, як згадується в інших відповідях, є «вогнем і забудьте» і не вимагає повідомлення у відповідь. З цієї причини DoS-атаки бувають майже виключно у вигляді пакетів UDP.

У контексті переповнення стека та сімейних сайтів питання, порушене Takaun Daikon, є дуже актуальним. Є багато способів отримати нову IP-адресу від свого провайдера. Зміна MAC-адреси очевидно найпростіше і працює для багатьох провайдерів. Крім того, багато людей, які страждають на глузливість, можуть використовувати загальнодоступні проксі або TOR. Очевидно, що блокування IP-джерела для цих пакетів просто блокує проксі-сервер або вузол завершення TOR.

Так чи дійсне блокування IP-адрес? Чорт так, так і є. Але ви закінчите з помилками. Ви заблокуєте деякі IP-адреси, які насправді не є джерелом проблеми (тобто проксі-сервери), і ви також отримаєте людей, які уникають ваших блоків шляхом зміни IP-адрес. Людина, якій не пощастило отримати заборонений IP пізніше, не зможе отримати доступ до сімейства сайтів SO. Але помилка швидкість повинна бути невеликою. Якщо ви не блокуєте величезні набори IP-адрес. Але якщо ви блокуєте один-два на день, вам слід добре.

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

Підробка IP-файлів триватиме, оскільки провайдери ліниві.

Мій проклятий провайдер добре знає, що я за певною адресою або, принаймні, в підмережі, в якій я перебуваю. Але я можу використовувати будь-яку адресу джерела. Чому так? Просто, вартість.

Якщо я підробляю кілька адрес тут і там, це не коштує мого провайдера нічого. Якби кожен користувач мого провайдера підробляв один пакет між 1:00 та 2:00, це було б навряд чи проскоком на радарі. Однак, коли ботнет надсилає багато підроблених пакетів від багатьох хостів у багатьох провайдерах, цільова машина або мережа перепадає.

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

UDP та ICMP найпростіше підробити, але можливий і TCP. Для цього потрібна незахищена віддалена ОС, яка використовує передбачувані порядкові номери для використання. Іноді машини для балансування навантаження змінюють порядкові номери та роблять їх передбачуваними. Отже, TCP можливий - але важче.

DNS-анти-підробляння зосереджується здебільшого на стороні безпеки, щоб не допустити, щоб хтось подав неправдиву відповідь на рекурсивний вирішувач. Затоплені аспекти UDP не є специфічними для DNS, окрім одного невеликого запиту (скажімо, для '.') Викличе досить велику відповідь. Таким чином, він робить приємний вектор посилення. Існує багато інших протоколів UDP, які працюють, але DNS використовується скрізь, і легко знайти машини, які використовуються для посилення атак.

DNSSEC робить це ще гірше, з UDP-пакетами, які можуть досягати розміру 4 к.

IP-адреси тривіально підробляти, що стосується DOS-атак на основі DNS (D), оскільки вони, як правило, стосуються UDP-пакетів, що захищаються та забувають. Для HTTP-трафіку це не так, тому вам потрібно буде або бути в тій же локальній мережі, що і веб-сервер (цілком можливо, звичайно, залежно від місця розміщення вашого веб-сайту), або контролювати проміжні маршрутизатори.

Ви можете надіслати листа будь-кому, і якщо ви не помістите зворотну адресу на конверт (або не поставите неправильну), вони можуть найняти всі фільтри фіксованої пошти у світі і не відфільтрувати ваше повідомлення без відкриття (обробка) ) це.

Однак, якщо відправник хоче відповіді, повернення адреси краще бути правильним, або для отримання правильної адреси повинен бути механізм рівня додатків. Тож я можу змусити вас думати, що ви відкриваєте лист від Nana, але навіть якщо я обдурюю вас змістом листа, ви не збираєтесь надсилати Нані чек, зроблений до CASH, на якусь адресу в Нігерії (якщо Нана не є нігерійською) ). Тож виклик / відповідь - це ефективний захист, якщо ви також не є Людиною середніх.

Я можу встановити в дейтаграмі будь-яку IP-адресу джерела, яку хочу.
Чи дозволить мій провайдер випустити такий пакет у дику природу - інше питання.

Хоча це, безумовно, реальність, яку потрібно вирішити, основна проблема справді нетехнічна: люди зі злісними намірами намагаються робити шкідливі речі. Тому справжнє рішення має бути і нетехнічним.

Я думаю, що зроблено Stackoverflow - це ТОЧНО правильне рішення для обробки другої лінії захисту: методи обмеження потенційних користувачів спаму через різні способи обмеження їхніх можливостей взаємодіяти з платформою до досягнення певного рівня «довіри».

Не тільки ці методи допомагають покращити загальну якість сайту, вони фактично стимулюють користувачів активізуватися та надавати більш надійні / достовірні відповіді.

З технічної точки зору, найкраще робити це було б зробити так, як пропонує Google: просто бути ефективним у поглинанні / справі з додатковим навантаженням.

Чудова робота та продовжуйте вдосконалюватися!

UDP є основною частиною того, чому це просто - насправді, Skype і Slingbox використовують можливість легко підробляти IP-адреси в UDP, щоб « пробивати » через NAT і дозволяти легко робити одноранговий.

TCP складніше, оскільки він вимагає повного циклу SYN / ACK, але ви все одно можете залити сервер висячими SYN-пакетами, які йдуть на IP-адреси багато-хоп далеко і, по суті, пов’язують величезну кількість маршрутизаторів у процесі.

Як було сказано вище, використання проксі-серверів є тривіальним, і існує дуже велика кількість відкритих анонімних проксі-серверів.

Навіть не використовуючи проксі, я можу встановити MAC-адресу на брандмауері будь-яке нове довільне значення, скинути мій кабельний модем, і мій провайдер призначить мені абсолютно нову блискучу IP-адресу.

І це лише для початку. Існує багато інших способів обійти заборони на IP.

Якщо так, то які пом'якшення можливі?

Не дуже багато можна зробити на приймальній стороні.

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

У конфігурації маршрутизатора є лише кілька рядків, тому немає гарного приводу для цього.

Існує спосіб відстежити нападника, але він потребує співпраці з вашими постачальниками вище: http://www.cymru.com/Documents/dos-and-vip.html

Як зазначали інші, UDP досить тривіально підробляти, TCP - не так вже й багато.

Кращою обороною, але, на жаль, не є універсальним, є фільтри виходу.

Для провайдерів, що працюють з послугами DSL тощо, кожна віртуальна лінія повинна бути налаштована ip verify unicast reverse-path(або як би не було еквівалентом Cisco), який блокує будь-який пакет, чия вихідна IP-адреса не знаходиться в діапазонах, які, як відомо, спрямовані вниз по цій лінії.

Я пам’ятаю, як займався програмуванням сокетів наприкінці 90-х з тим, що було, мабуть, Visual Basic, і ми могли встановити вихідний IP на нашому підключенні. Я неясно пам'ятаю, що коли ми його спробували, netstat -an показав фактичний IP-код джерела, але журнали Apache показали підроблений IP; і я думаю, що Apache передав підроблений IP модулям perl і так далі.