Како да изберете ефикасна политика за заштитен ѕид за да ги обезбедите вашите сервери

Вовед

Користењето на заштитен ѕид е исто толку за донесување интелигентни политички одлуки колку и за учење на синтаксата. Заштитните ѕидови како iptables се дизајнирани да спроведуваат политики со толкување на правила поставени од администраторот. Сепак, како администратор, треба да знаете кои видови правила имаат смисла за вашата инфраструктура.

Додека другите водичи се фокусираат на командите потребни за да се вклучи и работи, во овој водич ќе разговараме за некои од одлуките што ќе треба да ги донесете при имплементирање на заштитен ѕид. Овие избори ќе влијаат на тоа како се однесува вашиот заштитен ѕид, колку е заклучен вашиот сервер и како ќе реагира на различни услови што се случуваат. Ќе користиме iptables како конкретен пример, но повеќето од концептите ќе бидат широко применливи.

Одлучување за стандардна политика

Кога се конструира заштитен ѕид, една од најважните одлуки што треба да се донесе е стандардната политика. Ова одредува што се случува кога сообраќајот не е усогласен со други правила. Стандардно, заштитниот ѕид може или да ПРИФАТИ каков било сообраќај што не се совпаѓа со претходните правила, или да го ПОСТАВИ тој сообраќај.

Стандардно паѓање наспроти стандардно прифаќање

Стандардната политика на ACCEPT значи дека секој неспоредлив сообраќај е дозволен да влезе во серверот. Ова генерално не се препорачува, бидејќи тоа значи дека од таму ќе треба да работите наназад, блокирајќи го целиот несакан сообраќај. Пристапите од типот на блок листа се тешки за управување, бидејќи треба да го предвидите и блокирате секој тип на несакан сообраќај. Ова може да доведе до главоболки за одржување и генерално е подложно на грешки, погрешни конфигурации и неочекувани дупки во воспоставената политика.

Алтернативата е стандардна политика на DROP. Ова значи дека нема да биде дозволен секој сообраќај што не одговара на експлицитно правило. Секоја услуга мора да биде експлицитно дозволена, што може да изгледа како значителна количина на предна конфигурација. Сепак, ова значи дека вашата политика се стреми кон безбедноста и дека точно знаете што е дозволено да прима сообраќај на вашиот сервер. Исто така, скоро сите претходно конфигурирани политики ќе го следат овој пристап, што значи дека може да се надоврзувате на постоечките стандардни поставки.

Стандардна политика за отфрлање наспроти правило за конечно отфрлање

Изборот на стандардна политика за паѓање води до друга суптилна одлука. Со iptables и други слични заштитни ѕидови, стандардната политика може да се постави со помош на вградената функционалност на политиката на заштитниот ѕид или да се имплементира со додавање на правило за отфрлање на сите на крајот од списокот со правила.

Разликата помеѓу овие два методи се сведува на тоа што се случува ако правилата за заштитен ѕид се исчистат.

Ако вградената функција на политиката на вашиот заштитен ѕид е поставена на DROP и правилата на вашиот заштитен ѕид се исчистат (ресетираат) или ако се отстранат одредени правила за совпаѓање, вашите услуги веднаш ќе станат недостапни од далечина. Ова често е добра идеја кога поставувате политика за некритични услуги, така што вашиот сервер не е изложен на злонамерен сообраќај ако правилата се отстранат.

Лошата страна на овој пристап е што вашите услуги ќе бидат целосно недостапни за вашите клиенти додека повторно не воспоставите попустливи правила. Можете дури и потенцијално да се заклучите надвор од серверот ако немате локален или веб-базиран далечински пристап како алтернатива.

Алтернативата за поставување политика за паѓање со користење на вградената функционалност на политиката е да ја поставите стандардната политика на вашиот заштитен ѕид на ACCEPT и потоа да имплементирате политика DROP со редовни правила. Можете да додадете нормално правило за заштитен ѕид на крајот од вашиот синџир што се совпаѓа и го негира целиот преостанат неспоредлив сообраќај.

Во овој случај, ако правилата за заштитен ѕид се исчистени, вашите услуги ќе бидат достапни, но незаштитени. Во зависност од вашите опции за локален или алтернативен пристап, ова може да биде неопходно зло за да се осигурате дека можете повторно да го внесете вашиот сервер доколку правилата се исчистени. Ако одлучите да ја користите оваа опција, погрижете се правилото за фаќање сите секогаш да остане последно правило во вашата група правила.

Испуштање наспроти отфрлање сообраќај

Постојат неколку различни начини да се спречи пакетот да стигне до својата наменета дестинација. Изборот меѓу нив има влијание врз тоа како клиентот го перцепира обидот за поврзување и колку брзо тие можат да утврдат дека нивното барање нема да биде услужено.

Првиот начин на кој може да се негираат пакетите е со DROP. Drop може да се користи како стандардна политика или како цел за правилата за совпаѓање. Кога пакетот ќе се испушти, iptables само го фрла. Тој не испраќа никаков одговор назад до клиентот кој се обидува да се поврзе и не дава никакви индикации дека воопшто ги примил дотичните пакети. Ова значи дека клиентите (легитимни или не) нема да добијат никаква потврда за приемот на нивните пакети.

За обиди за поврзување со TCP (како што се врските направени од веб-прелистувач), врската ќе престане додека не се достигне ограничувањето за истекување. Недостатокот на одговор за клиентите на UDP е уште понејасно. Всушност, непримањето назад UDP пакет често е показател дека пакетот бил прифатен. Ако клиентот на UDP се грижи за приемот на неговите пакети, ќе мора повторно да ги испрати за да се обиде да утврди дали се прифатени, изгубени во транзит или испуштени. Ова може да го зголеми времето што злонамерниот актер ќе треба да го потроши за да добие информации за состојбата на портите на вашиот сервер, но исто така може да предизвика проблеми со легитимниот сообраќај.

Алтернатива за отфрлање на сообраќајот е експлицитно да ги одбиете пакетите што не ги дозволувате. ICMP, или Интернет контролен протокол за пораки, е мета-протокол што се користи низ интернет за испраќање пораки за статус, дијагностика и грешка помеѓу домаќините како канал надвор од опсегот кој не се потпира на конвенционалните протоколи за комуникација како TCP или UDP. Кога ја користите целта REJECT наместо целта DROP, сообраќајот е одбиен и ICMP пакет се враќа на испраќачот за да го информира дека нивниот сообраќај е примен, но нема бидат прифатени. Може да се вклучи и статусна порака за да се даде причина.

Ова има голем број на последици. Под претпоставка дека сообраќајот на ICMP е дозволено да стигне до клиентот, тие веднаш ќе бидат известени дека нивниот сообраќај е блокиран. За легитимните клиенти, тоа значи дека тие можат да контактираат со администраторот или да ги проверат нивните опции за поврзување за да се осигураат дека допираат до правилната порта. За злонамерните корисници, тоа значи дека можат да ги завршат своите скенирања и да ги мапираат отворените, затворените и филтрираните порти за пократок временски период.

Има многу што треба да се разгледа кога се одлучува дали да се откаже или одбие сообраќајот. Една важна грижа е дека најголемиот дел од злонамерниот сообраќај всушност ќе биде извршен од автоматизирани скрипти. Бидејќи овие скрипти обично не се надгледуваат, отфрлањето на нелегитимниот сообраќај нема значајно да ги обесхрабри и ќе има негативни ефекти за легитимните корисници. Повеќе за оваа тема можете да најдете на веб-страницата на Питер Бени.

Табела за одговор на пад наспроти одбивање

Табелата подолу покажува како серверот заштитен со заштитен ѕид ќе реагира на различни барања во зависност од политиката што се применува на одредишната порта.

Првата колона го означува типот на пакет испратен од клиентот. Втората колона ги содржи командите nmap кои може да се користат за тестирање на секое сценарио. Третата колона ја означува политиката за пристаниште што се применува на пристаништето. Четвртата колона е одговорот што серверот ќе го испрати назад, а петтата колона е она што клиентот може да го заклучи за портата врз основа на одговорот што го добил.

Политики на ICMP

Како и при одлучувањето дали да го отфрлите или одбиете одбиениот сообраќај, имате опција да ги прифатите или отфрлите ICMP пакетите наменети за вашиот сервер.

ICMP е протокол што се користи за многу работи. Како што споменавме, честопати се испраќа назад за да се дадат информации за статусот за барањата кои користат други протоколи. Една од неговите најпопуларни функции е испраќање и одговарање на мрежни пингови за да се потврди поврзаноста со оддалечените хостови. Постојат многу други намени за ICMP кои не се толку широко познати, но сепак корисни.

ICMP пакетите се организирани по „тип“, а потоа понатаму по „код“. Еден тип го одредува општото значење на пораката. На пример, Тип 3 значи дека дестинацијата била недостапна. Код често се користи за давање дополнителни информации за типот. На пример, ICMP Type 3 Code 3 значи дека одредишната порта е недостапна, додека ICMP Type 3 Code 0 значи дека не може да се достигне одредишната мрежа.

Некои типови ICMP се застарени, така што тие можат безусловно да се блокираат. Меѓу нив се ICMP извор на гаснење (тип 4 код 0) и алтернативен домаќин (тип 6). Сите типови 1, 2, 7 и тип 15 и погоре се застарени, резервирани за идна употреба или експериментални. Многу шаблони на заштитниот ѕид нагоре ќе се справат со ова стандардно.

Видови за блокирање во зависност од мрежната конфигурација

Некои типови ICMP се корисни во одредени мрежни конфигурации, но треба да бидат блокирани во други.

На пример, пораките за пренасочување на ICMP (тип 5) може да бидат корисни за осветлување на лошиот дизајн на мрежата. ICMP пренасочување се испраќа кога подобра рута е директно достапна на клиентот. Значи, ако рутерот прими пакет што ќе треба да биде пренасочен до друг домаќин на истата мрежа, тој испраќа порака за пренасочување на ICMP за да му каже на клиентот да ги испрати пакетите преку другиот домаќин во иднина.

Ова е корисно ако имате доверба во вашата локална мрежа и сакате да забележите неефикасност во вашите табели за рутирање при почетната конфигурација. На недоверлива мрежа, злонамерен корисник потенцијално може да испрати ICMP пренасочувања за да манипулира со рутирачките табели на хостовите.

Други типови ICMP кои се корисни во некои мрежи и потенцијално штетни во други се ICMP реклама за рутер (тип 9) и пакети за повикување рутер (тип 10). Пакетите за рекламирање и повикување на рутер се користат како дел од IRDP (ICMP Internet Router Discovery Protocol), систем кој им овозможува на домаќините, по подигнувањето или приклучувањето на мрежата, динамички да откриваат достапни рутери.

Во повеќето случаи, подобро е домаќинот да има статични правци конфигурирани за портите што ќе ги користи. Овие пакети треба да се прифатат во истите ситуации како и пакетите за пренасочување на ICMP. Всушност, бидејќи домаќинот нема да ја знае претпочитаната рута за сообраќај од која било откриена рута, пораките за пренасочување често се потребни директно по откривањето. Ако не извршувате услуга што испраќа пакети за барање на рутер или ги менува вашите маршрути врз основа на пакети за реклами (како rdisc), можете безбедно да ги блокирате овие пакети.

Типови кои често се безбедни за да се дозволат

Видовите ICMP кои обично се безбедни за дозвола се подолу, но можеби ќе сакате да ги оневозможите ако сакате да бидете дополнително внимателни.

• Тип 8 — Барање за ехо: ова се барања за пинг насочени кон вашиот сервер. Обично е безбедно да ги дозволите (негирањето на овие пакети не го крие вашиот сервер, бидејќи има многу други начини за корисниците да дознаат дали вашиот хост е вклучен), но можете да ги блокирате или да ги ограничите изворните адреси на кои одговарате. ако сакате.
• Тип 13 — Барање за временски печат: овие пакети може да ги користат клиентите за собирање информации за латентност. Тие можат да се користат во некои техники за отпечатоци од прсти на ОС, за да можете да ги блокирате или да го ограничите опсегот на адреси на кои одговарате.

Типовите подолу обично може да се дозволат без експлицитни правила со конфигурирање на вашиот заштитен ѕид да дозволува одговори на барањата што ги направил (со користење на модулот conntrack за да се дозволи ESTABLISHED и RELATED сообраќај).

• Тип 0 — Одговори со ехо: ова се одговори на барања за ехо (пинг).
• Тип 3 — Дестинацијата недостижна: легитимните недостижни пакети се одговори на барањата создадени од вашиот сервер што укажуваат дека пакетот не може да се испорача.
• Тип 11 — Надминато време: ова е вратена дијагностичка грешка ако пакетот генериран од вашиот сервер умрел пред да стигне до дестинацијата поради надминување на неговата вредност TTL.
• Тип 12 — Проблем со параметарот: Ова значи дека појдовниот пакет од вашиот сервер е погрешно формиран.
• Тип 14 — Одговори со временски печат: ова се одговорите за барањата за временски печат генерирани од вашиот сервер.

Блокирањето на целиот дојдовен сообраќај на ICMP сè уште се препорачува од некои безбедносни експерти, но многу луѓе сега поттикнуваат интелигентни политики за прифаќање на ICMP. нишките имаат повеќе информации.

Ограничување на врската и ограничување на стапката

За некои услуги и обрасци на сообраќај, можеби ќе сакате да дозволите пристап само додека клиентот не го злоупотребува тој пристап. Два начини за ограничување на користењето на ресурсите се ограничување на врската и ограничување на стапката.

Ограничување на врската

Ограничувањето на врската може да се имплементира со помош на екстензии како connlimit за да се провери колку активни конекции има отворено клиентот. Ова може да се користи за ограничување на бројот на дозволени врски во исто време. Ако одлучите да наметнете ограничувања за поврзување, ќе треба да донесете некои одлуки:

• Дали ограничувате по адреса, по мрежа или глобална основа?
• Дали одговарате и ограничувате сообраќај за одредена услуга или за серверот како целина?

Врските може да се ограничат на основа на домаќин до домаќин, или може да се постави ограничување за мрежен сегмент со обезбедување на мрежен префикс (како што е опсегот на IP адреса за цела организација). Можете исто така да поставите глобален максимален број на конекции за услуга или за целата машина. Имајте на ум дека е можно да се измешаат и да се совпаднат за да се создадат посложени политики за контрола на броевите на вашите конекции.

Ограничување на стапката

Ограничувањето на стапката ви овозможува да конструирате правила што ја регулираат стапката или фреквенцијата со која сообраќајот ќе биде прифатен од вашиот сервер. Постојат голем број на различни екстензии на заштитен ѕид што може да се користат за ограничување на стапката, вклучувајќи ги limit, hashlimit и неодамнешни. Изборот на екстензијата што ја користите ќе зависи во голема мера од начинот на кој сакате да го ограничите сообраќајот.

Екстензијата limit ќе предизвика усогласување на правилото за прашање додека не се достигне лимитот, по што ќе се исфрлат дополнителните пакети. Ограничувањето како 5/sec ќе дозволи 5 пакети да се совпаѓаат во секунда, по што правилото повеќе не се совпаѓа. Ова е добро за поставување глобална граница на стапка за услуга. Можете исто така да распоредите дополнителна услуга како Fail2ban за да блокирате повторени обиди за поврзување.

Екстензијата hashlimit е пофлексибилна, овозможувајќи ви да одредите некои од вредностите што iptables ќе ги хешира за да оцени совпаѓање. На пример, може да ја погледне изворната адреса, изворната порта, дестинационата адреса, дестинацијата или комбинацијата од тие четири вредности за да го оцени секој запис. Може да се ограничи по пакети или по примени бајти. Ова обезбедува флексибилно ограничување на стапката по клиент или по услуга.

Наставката recent динамички додава IP адреси на клиентот во список или проверува постоечка листа кога правилото се совпаѓа. Ова ви овозможува да ја проширите вашата ограничувачка логика низ голем број различни правила за сложени модели. Има можност да одреди број на хитови и временски опсег како другите ограничувачи, но исто така може да го ресетира временскиот опсег ако се види дополнителен сообраќај, принудувајќи го клиентот да го запре целиот сообраќај ако е ограничен.

Монолитен против менаџмент базиран на синџири

Сите правила за заштитен ѕид iptables и nftables во суштина се вкоренети во проширувањето на вградените синџири. За почеток, ова обично значи промена на стандардната политика за постојните синџири и додавање правила. За посложени заштитни ѕидови, често е добра идеја да се прошири рамката за управување со создавање дополнителни синџири.

Синџирите креирани од корисникот се нарекуваат секундарно и инхерентно се поврзани со нивниот \синџир на повикување, од кој потекнуваат. Синџир на повикување и продолжете со евалуација Имајќи го тоа на ум, синџирите создадени од корисникот главно се корисни за организациски цели, за да се направат условите за усогласување на правилата поодржливи и да се подобри читливоста со разделување на условите за совпаѓање.

Ако се откриете дека повторувате одредени критериуми за совпаѓање за значителен број правила, можеби е вредно да креирате правило за скок со споделените критериуми за совпаѓање во нов синџир. Внатре во новиот синџир, можете да го додадете тој сет на правила со испуштени вишок критериуми за совпаѓање.

Одлуката дали да ги соберете сите ваши правила во еден од вградените синџири или дали да креирате и користите дополнителни синџири ќе зависи од тоа колку е сложено вашиот сет на правила.

Заклучок

Сега треба да имате подобро разбирање за одлуките што ќе треба да ги донесете при дизајнирање на политики за заштитен ѕид за вашите сервери. Вообичаено временската инвестиција поврзана со заштитните ѕидови во голема мера се искривува кон првичното поставување. Иако може да биде потребно извесно време и експериментирање за да се дојде до политика која најдобро ги задоволува вашите потреби, тоа ќе ви даде поголема контрола врз безбедноста на вашиот сервер.

Ако сакате да дознаете повеќе за заштитните ѕидови и за iptables конкретно, проверете ги следните написи:

• Како работи заштитниот ѕид на Iptables
• Длабоко нурне во архитектурата на Iptables и Netfilter

Следниве водичи може да ви помогнат да ги имплементирате вашите политики. Изберете го водичот што одговара на вашиот заштитен ѕид за да започнете:

• Како да поставите заштитен ѕид користејќи Nftables на Ubuntu 22.04
• Како да поставите заштитен ѕид со UFW на Ubuntu 22.04
• Како да поставите заштитен ѕид користејќи FirewallD на Rocky Linux 9