Ця стаття є четвертою у циклі статей "Як взяти мережеву інфраструктуру під свій контроль". Зміст усіх статей циклу та посилання можна знайти тут.

В першій частині цього розділу ми розглянули деякі аспекти мережевої безпеки сегмента Data Center. Ця частина буде присвячена "Internet Access" сегменту.

Доступ в інтернет

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

При аудиті цього сегмента зверніть увагу на такі аспекти:

• дизайн
• налаштування BGP
• DOS/DDOS захист
• фільтрація трафіку на фаєрволі

Дизайн

Як приклад дизайну цього сегменту для мережі підприємства я б порекомендував керівництво від Cisco у рамках SAFE моделі.

Звичайно, можливо, рішення інших вендорів здасться вам привабливішим (див. квадрант Гартнера за 2018), але, не закликаючи вас дотримуватися деталей цього дизайну, я все ж таки вважаю корисним розібратися в принципах та ідеях, що лежать в його основі.

зауваження

У SAFE сегмент "Remote Access" є частиною "Internet Access". Але в даному циклі статей ми розглядатимемо його окремо.

Стандартним набором обладнання у цьому сегменті для мережі підприємства (enterprise network) є

• граничні маршрутизатори (border routers)
• фаєрволи

зауваження 1

У цьому циклі статей, коли я говорю про фаєрволів, я маю на увазі NGFW.

зауваження 2

Я опускаю розгляд різних L2/L1 або оверлейних L2 over L3 рішень необхідних для забезпечення L1/L2 зв'язності і обмежуюсь лише питаннями рівня L3 і вище. Частково питання L1/L2 було розглянуто у розділі «Чищення та документування".

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

Давайте, як і в попередньої частини, почнемо з питання, а чи є необхідним використання фаєрволу в даному сегменті у вашому випадку?

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

Приклад 1. затримка

У тому, що стосується інтернету, немає сенсу говорити про затримки навіть близько 1 мілісекунди. Тому затримка в даному сегменті не може бути фактором, що обмежує використання фаєровалу.

Приклад 2. Продуктивність

У деяких випадках цей фактор, як і раніше, може бути суттєвим. Тому, можливо, частину трафіку (наприклад, трафік балансувальників навантаження) вам доведеться пустити в обхід фаєрволу.

Приклад 3. Надійність

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

Так, припустимо, що ваш сервіс живе поверх http/https (з короткими сесіями). У цьому випадку ви можете використовувати дві незалежні коробки (без HA) і при проблемі з однією з них по роутингу переводити весь трафік на другу.

Або ви можете використовувати фаєрволи в трансперент моді і при виході їх з ладу на час вирішення проблеми пускати трафік в обхід фаєрволів.

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

Важливо!

Виникає спокуса поєднати цей фаєрвол із фаєрволом дата-центру (використовувати один фаєрвол для цих сегментів). Рішення, у принципі, можливе, але заодно треба розуміти, що т.к. «Internet Access» фаєрвол фактично стоїть на передньому краї вашої оборони і «приймає на себе» принаймні частину шкідливого трафіку, то, звичайно, потрібно враховувати підвищений ризик того, що фаєрвол буде виведений з ладу. Тобто, використовуючи одні й самі пристрої у двох цих сегментах, ви істотно знизите availability вашого дата-центр сегмента.

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

Приклад

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

Для BGP вам зовсім не обов'язково мати виділені маршрутизатори, ви можете використовувати open-source інструменти, наприклад, квагга. Тому, можливо, все, що вам потрібно – це сервер або кілька серверів, комутатор та BGP.

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

Ви можете мати кілька дата-центрів з повноцінним захистом (фаєрволи, сервіси захисту від DDOS, що надаються вашими інтернет-провайдерами) і десятки або сотні «спрощених» точок присутності тільки з L2 комутаторами та серверами.

А як же захист у цьому випадку?

Давайте розглянемо, наприклад, популярну останнім часом DNS Amplification DDOS атаку. Її небезпека полягає в тому, що генерується велика кількість трафіку, який просто «забиває» на 100% усі ваші аплінки.

Що ми маємо у разі нашого дизайну.

• якщо ви використовуєте AnyCast, трафік розподіляється між вашими точками присутності. Якщо сумарна смуга пропускання у вас терабіти, то це само по собі фактично (все ж таки останнім часом було кілька атак зі шкідливим трафіком порядку терабіту) оберігає вас від «переповнення» аплінків
• якщо все ж таки якісь аплінки «забилися», то ви просто виводите цей майданчик з обслуговування (перестаєте анонсувати префікс)
• ви також можете збільшити частку трафіку, що віддається з ваших "повноцінних" (і, відповідно, захищених) дата-центрів, таким чином, прибравши істотну частину шкідливого трафіку з незахищених точок присутності

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

Налаштування BGP

Тут дві теми.

• Зв'язок
• Налаштування BGP

Про зв'язковість ми вже трохи говорили в частини 1. Суть у тому, щоб трафік до ваших клієнтів ходив оптимальним шляхом. Хоча оптимальність — це не завжди лише про затримку, але зазвичай саме низька затримка є основним показником оптимальності. Для якихось компаній це важливіше, для інших менш. Все залежить від сервісу, який ви надаєте.

Приклад 1

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

Приклад 2

Якщо ви ігрова компанія, і для вас важливі десятки мілісекунд, то, звичайно, зв'язність для вас дуже важлива.

Приклад 3

Також треба розуміти, що, з властивостей протоколу TCP, швидкість передачі у межах однієї TCP сесії також залежить від RTT (Round Trip Time). CDN мережі будуються навіть для вирішення цієї проблеми, виносячи сервера роздачі контенту ближче до споживача цього контенту.

Дослідження зв'язності – це окрема цікава тема, гідна окремої статті чи серії статей і потребує хорошого розуміння, як «влаштований» інтернет.

Корисні ресурси:

ripe.net
bgp.he.net

Приклад

Наведу лише один маленький приклад.

Припустимо, що ваш дата центр знаходиться в Москві, і у вас є єдиний аплінк - Ростелеком (AS12389). В цьому випадку (single homed) BGP вам не потрібен, і як публічні адреси ви, швидше за все, використовуєте адресний пул від Ростелекому.

Припустимо, що ви надаєте якийсь сервіс, і у вас достатньо клієнтів з України, і вони скаржаться на великі затримки. При дослідженні ви з'ясували, що IP-адреси деяких з них знаходяться в сітці 37.52.0.0/21.

Виконавши traceroute, ви побачили, що трафік йде через AS1299 (Telia), а виконавши ping ви отримали середній RTT 70 - 80 мілісекунд. Ви можете побачити це також на looking glass Ростелекому.

Утилітою whois (на сайті ripe.net або локальною утилітою) ви легко можете визначити, що блок 37.52.0.0/21 належить AS6849 (Ukrtelecom).

Далі, зайшовши на bgp.he.net ви бачите, що AS6849 не має стосунків з AS12389 (вони не є ні клієнтами, ні аплінками один одному, так само у них немає пірінгу). Але якщо ви подивіться на список бенкетів для AS6849, то ви побачите, наприклад, AS29226 (Mastertel) та AS31133 (Megafon).

Знайшовши looking glass цих провайдерів, ви можете порівняти шлях та RTT. Наприклад, для Mastertel RTT буде вже близько 30 мілісекунд.

Отже, якщо різниця між 80 і 30 мілісекундами істотна для вашого сервісу, то, можливо, вам потрібно задуматися про зв'язковість, отримати в RIPE свій номер AS, свій пул адрес і підключити додаткові аплінки та/або створити точки присутності на IX-ах.

При використанні BGP ви не тільки маєте можливість покращити зв'язність, але також резервуєте підключення до інтернету.

Цей документ містить рекомендації щодо налаштування BGP. Незважаючи на те, що ці рекомендації були вироблені на основі «best practice» провайдерів, все ж таки (якщо ваші BGP налаштування не зовсім вже елементарні) вони є безперечно корисними і фактично повинні бути частиною hardening-а, який ми обговорювали в першій частині.

DOS/DDOS захист

Наразі DOS/DDOS атаки стали повсякденною реальністю для багатьох компаній. Насправді, у тому чи іншому вигляді, вас атакують досить часто. Те, що ви поки не помічаєте цього, говорить лише про те, що поки не була організована цілеспрямована атака проти вас, і що ті засоби захисту, якими ви користуєтеся, навіть, можливо, не підозрюючи про це (різні вбудовані захисту операційних систем), достатні, щоб деградація сервісу, що надається, була мінімізована для вас і ваших клієнтів.

Існують інтернет-ресурси, які на основі логів з обладнання в режимі реального часу малюють гарні карти атак.

Тут можна знайти посилання на них.

Моя улюблена карта від CheckPoint.

Захист від DDOS/DOS зазвичай є ешелонованим. Щоб зрозуміти чому, треба розуміти, які типи DOS/DDOS атак існують (див. наприклад, тут або тут)

Тобто ми маємо три типи атак:

• volumetric attacks
• protocol attacks
• application attacks

Якщо від останніх двох типів атак ви можете захиститися самостійно з використанням, наприклад, фаєрволів, то від атак, спрямованих на «переповнення» ваших аплінків, ви самі не захиститеся (звичайно, якщо ваша сумарна ємність інтернет-каналів не обчислюється терабітами, а краще десятками терабіт).

Тому перша лінія захисту - це захист від «volumetric» атак і забезпечити цей захист вам повинен ваш провайдер або провайдери. Якщо ви цього ще не усвідомили, то поки що вам просто щастить.

Приклад

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

На час атаки вам доведеться частково пожертвувати зв'язністю. Але

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

Захист від "protocol attacks" та "application attacks" ви також можете віддати на відкуп партнерам.
Ось тут ви можете почитати гарне дослідження (переклад). Правда, стаття дворічної давності, але це дасть вам уявлення про підходи, як ви можете захиститися від атак DDOS.

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

Тому давайте розглянемо, як організувати другу та третю лінії оборони (як додаток до захисту від провайдера).

Отже, друга лінія захисту – це фільтрація та обмежувачі трафіку (policers) на вході у вашу мережу.

Приклад 1

Припустимо, що ви "закрилися парасолькою" від DDOS за допомогою одного з провайдерів. Припустимо, що цей провайдер використовує Arbor для фільтрації трафіку та фільтри на межі своєї мережі.

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

Припустимо, що йде атака SYN flood. Навіть якщо ви замовили послугу, коли в разі атаки трафік автоматично перекладається на фільтрування, це не відбувається миттєво. Протягом хвилини або більше ви залишаєтеся під атакою. І це може призвести до виходу з ладу обладнання або деградації сервісу. У цьому випадку обмеження трафіку на граничному маршрутизації, хоча, і призведе до того, що деякі TCP сесії протягом цього часу не будуть встановлюватися, але врятує вашу інфраструктуру від більш масштабних проблем.

Приклад 2

Аномально велика кількість SYN пакетів може бути не тільки результатом атаки SYN flood. Припустімо, що ви надаєте сервіс, при якому у вас одночасно може бути близько 100 тисяч TCP коннекцій (в один дата-центр).

Припустимо, що в результаті короткочасної проблеми з одним із ваших основних провайдерів у вас "кікнулося" половина сесій. Якщо ваша програма влаштована таким чином, що вона, «недовго думаючи», відразу (або через якийсь однаковий для всіх сесій інтервал часу) намагається перевстановити з'єднання, то приблизно одночасно отримаєте як мінімум 50 тисяч SYN пакетів.

Якщо поверх цих сесій у вас, наприклад, повинен працювати ssl/tls handshake, що передбачає обмін сертифікатами, то з точки зору вичерпання ресурсів для вашого балансувальника навантаження це буде набагато сильніший «DDOS» ніж простий SYN flood. Здавалося б, балансувальники мають відпрацьовувати такі події, але… на жаль, ми зіткнулися на повне зростання з такою проблемою.

І звичайно, policer на граничному маршрутизаторі врятує ваше обладнання і в цьому випадку.

Третій рівень захисту від DDOS/DOS – це налаштування фаєрволу.

Тут ви можете усунути як атаки другого, так і третього типу. Загалом, все, що долетить до фаєрволу, можна буде відфільтрувати тут.

Порада

Постарайтеся дати фаєрволу якнайменше роботи, відфільтрувавши якнайбільше на перших двох лініях оборони. І ось чому.

З вами не відбувалося такого, що випадково, генеруючи трафік, щоб перевірити, наприклад, наскільки операційна система ваших серверів стійка до атак DDOS, ви “вбивали” свій фаєрвол, завантажуючи його на 100 відсотків, при цьому трафіком із звичайною інтенсивністю? Якщо ні, то, можливо, просто тому, що ви не куштували?

Загалом, фаєрвол, як я вже казав — складна штука, і він добре працює з відомими вразливістю та відтестованими рішеннями, але якщо ви надішлете щось незвичайне, просто якесь сміття або пакети з неправильними заголовками, то ви з деякою, не такою вже маленькою (виходячи з мого досвіду) ймовірністю можете ввести в ступор та топове обладнання. Тому на етапі 2 за допомогою звичайних ACL (на рівні L3/L4) пускайте у вашу мережу лише той трафік, який має туди входити.

Фільтрування трафіку на фаєрволі

Продовжуємо розмову про фаєрвол. Потрібно розуміти, що DOS/DDOS атаки – це лише один з різновидів кібер-атак.

Крім DOS/DDOS protection ми можемо ще мати щось на кшталт наступного списку можливостей:

• application firewalling
• threat prevention (antivirus, anti-spyware, and vulnerability)
• Фільтрація URL-адрес
• data filtering (content filtering)
• file blocking (file types blocking)

Вам вирішувати, що із цього списку вам потрібно.

Далі буде

Джерело: habr.com