USG/ATP/VPN - Основи на защитата на защитна стена

Серия защитни стени Zyxel от версия на фърмуера 5.35

Защитната стена е първата линия на защита срещу нападатели от интернет. Тя защитава локалната мрежа от неоторизиран достъп и е съществена част от концепцията за сигурност. Но какво става, ако самата защитна стена стане обект на хакерски атаки и следователно може да се превърне в потенциална заплаха? Следващото ръководство има за цел да предостави информация за това как да се атакуват възможностите, които могат да бъдат ограничени.

1. Контрол на политиката

2. Откриване и предотвратяване на аномалии

3. Отдалечено управление чрез HTTPS

4. Удостоверяване с два фактора

5. Протоколи за предупреждение

6. Автоматични актуализации на фърмуера

7. Защита на чувствителни данни

1. Контрол на политиката

Достъп до защитната стена трябва да имат толкова малко потребители, колкото е необходимо. За да се гарантира това, е препоръчително да се ограничат правата на достъп, доколкото е възможно.

Конфигурация > Политика за сигурност > Контрол на политиката

Зоната на ZyWALL поема определена роля. Тя съдържа всички интерфейсни адреси на защитната стена. За тази зона могат да се създават само правила.

Например адресът по подразбиране 192.168.1.1 не принадлежи към зона LAN1, а към зона ZyWALL.

При настройките по подразбиране достъпът до защитната стена е предимно отворен. Поради това те трябва да бъдат допълнително ограничени.

Ограничаване на правилата за контрол на политиката
Правилата за контрол на защитната стена могат да бъдат ограничени въз основа на няколко критерия. Основно три критерия са полезни за достъпа до защитната стена:
1. IPv4 източник (адресни обекти)
2. услуга
3. потребител

Тези елементи се създават като обекти.

Адреси-обекти
По принцип има три вида адресни обекти. Те са:
1. IP адреси
2. FQDN адреси
3. ГеоIP адреси

Обектите за адреси могат да се групират. Не е възможно обаче да се смесват различни типове адреси.

Конфигурация > Обект > Адрес/Geo IP > Адрес

1.1 IP адреси

Когато е възможно, трябва да се използват IP адреси, тъй като те са уникални. Съществуват няколко типа IP адреси:

1. хост > това описва един IP адрес
2. обхват > това може да бъде всеки обхват, определен от началния и крайния адрес
3. подмрежа > това може да се създаде чрез въвеждане на маска на подмрежата или CIDR (напр. /24)
4. интерфейс IP > поема IP адреса на даден интерфейс и се адаптира динамично
5. интерфейс подмрежа > поема динамично подмрежата на даден интерфейс
6. интерфейс gateway (шлюз) > поема шлюза на интерфейс от тип WAN или общ.

Хост, обхват, подмрежа
Типовете адреси Host (Домакин), Range (Обхват) и Subnet (Подмрежа) са особено подходящи като източници на IPv4. Ако достъпът се осъществява от WAN, се задава публичният IP адрес на отдалечената станция.
От локална мрежа тези обекти могат да се използват за създаване на групи с различни разрешения.
Интерфейс IP
Този обект може да се използва, ако достъпът е възможен само от определен IP адрес. Например, ако има 2 WAN интерфейса, но дадена услуга трябва да бъде достъпна само на единия интерфейс, IP адресът на интерфейса може да бъде въведен в правилото за контрол на политиката като IPv4 дестинация.
Подмрежа на интерфейса
Този тип адрес е подходящ, ако трябва да се създадат унифицирани правила за локален интерфейс (напр. LAN1).

Интерфейсен шлюз
Този тип адрес не е подходящ за достъп до защитната стена.
2. Обекти FQDN
При обектите FQDN вместо IP адрес може да се въведе име, например www,mydomain.com. Този тип запис е особено подходящ, ако достъпът се осъществява от WAN и отдалечената станция няма статичен публичен IP адрес. В този случай вместо IP адрес може да се използва име DynDNS. За обектите FQDN е необходим бърз DNS сървър. Възможни са и записи с уайлдкард, например *.mydomain.com. Те обаче не могат да се използват за тази цел.

1.2 FQDN обекти
При FQDN обектите вместо IP адрес може да се въведе име, например www,mydomain.com. Този тип запис е особено подходящ, ако достъпът се осъществява от WAN и отдалечената станция няма статичен публичен IP адрес. В този случай вместо IP адрес може да се използва име DynDNS. За обектите FQDN е необходим бърз DNS сървър. Възможни са и записи с уайлдкард, например *.mydomain.com. Те обаче не могат да се използват за тази цел.

Географски IP адреси

Гео IP адресите могат да се използват за създаване на обекти, базирани на държава или регион. Услугата използва външна база данни и трябва да се актуализира редовно. Geo IP не предлага надеждна защита, тъй като адресът на източника може да бъде манипулиран много лесно с помощта на свободно достъпни VPN услуги.

Обекти за услуги

Обектите за услуги се използват за определяне на това кои услуги да получат или да им бъде отказан достъп в настройките за контрол на политиката. Услугите могат да бъдат групирани. Услугите могат да се използват и на други места, например в маршрутите на политиката и NAT записите.
В допълнение към стандартните обекти за услуги има и някои специфични обекти. Това са обектите "Wiz_2FA, Wiz_HTTP, Wiz_HTTPS и Wiz_SSLVPN". Портът на тези услуги се адаптира автоматично, когато се предефинира в съответното меню.

Конфигурация > Обект > Услуга

Потребител
Конфигурация > Обект > Потребител

Съществуват различни типове потребители.
Администратор - може да прави промени в конфигурацията
Limited-admin (Ограничен администратор) - може да има достъп до конфигурацията, но не може да прави промени
User (Потребител) - може да се удостоверява чрез 2FA
Гост - може да влезе в защитната стена
Ext-user/ext-group-user - може да се удостоверява на външен сървър.

Вградените потребители са предварително дефинирани потребители, които не могат да бъдат изтривани и са предназначени за специфични цели.

Потребителите трябва да бъдат дефинирани така, че да имат само необходимите разрешения.
Обикновено потребителите на VPN или 802.1x се дефинират като потребители от тип Users (Потребители).

Сигурност при влизане
Определя дали и през какъв период трябва да се сменят паролите и дали се изисква сложност на паролата.
Настройки за влизане на потребителя
Определя колко пъти един потребител може да влезе в системата по едно и също време. Ако ограничението е зададено на "1", администраторът може да се блокира.
Настройки за блокиране на IP адреса на потребителя
Записите определят колко често се допуска въвеждане на грешна парола, докато потребителят бъде блокиран за определен период от време. Тази настройка предпазва от атаки с груба сила.

Препоръчителни правила за контрол на политиката
От: WAN Към: ZyWALL
Силно препоръчително е да затворите всички услуги, които не са изрично необходими.
Често необходими услуги:
IPSec VPN (IKEv1, IKEv2, L2TP):
ESP, IKE, NATT, (L2TP-UDP).

SSL VPN:
Wiz_SSLVPN

2-факторно удостоверяване за VPN:
Wiz_2FA

Отдалечен достъп чрез HTTP/HTTPS:
Wiz_HTTP, Wiz_HTTPS

За да се избегнат максимално рисковете за сигурността, най-добре е отдалеченото управление да се извършва чрез IPSec VPN. Адресите на източниците трябва да бъдат ограничени, ако е възможно. Не се препоръчва използването на SSL VPN, тъй като по този начин се предлага възможен вектор за атака чрез SSL.

Отдалечен достъп през HTTPS:
Ако е необходим отдалечен достъп чрез HTTP/HTTPS, адресът на източника винаги трябва да бъде ограничен до IP адрес или FQDN. GeoIP като адрес на източника не е сигурен и предлага значителен потенциал за атака. За управление чрез HTTPS се препоръчва да се използва алтернативен порт.

От: VPN зона Към: ZyWALL (от клиента към сайта)
По подразбиране всички портове са отворени. В повечето случаи са необходими само няколко услуги. Това са, например, DNS и L2TP-UDP. За други услуги достъпът трябва да бъде блокиран. Ако се желае отдалечено управление чрез VPN от клиент към сайт, достъпът до защитната стена може да бъде ограничен до един потребител. Това обаче работи само ако потребителят вече е влязъл в защитната стена, когато е бил създаден тунелът.

От: LAN Към: ZyWALL
Също така тук трябва да се ограничат правата за достъп. Пълен достъп до защитната стена трябва да се предоставя само на специална LAN за управление или на отделни IP адреси на администратори. За да работят правилно някои услуги, трябва да се предостави достъп до защитната стена. Това включва DNS, multicast, Radius-Auth, NetBIOS, SNMT, SSO и др. Кои достъпи са ефективно необходими, зависи до голяма степен от топологията на мрежата и използваните технологии.

2. Откриване и предотвратяване на аномалии (ADP)

Configuration (Конфигурация) > Security Policy (Политика за сигурност) > ADP
ADP осигурява защита срещу сканиране на портове и необичайно мрежово поведение. Препоръчва се активиране на ADP с профил по подразбиране от зоната WAN. При възникване на проблеми могат да се правят индивидуални корекции на профила.

В отделни случаи ADP може да повлияе на определени услуги. Това се отнася по-специално за откриването на наводнения. По тази причина защитата от наводнения може да бъде деактивирана за отделни услуги, например NATT. Такава настройка е полезна само при възникване на проблеми.

3. Отдалечено управление чрез HTTPS

Някои специфични настройки в настройките за WWW имат пряко въздействие върху сигурността на системата.

Конфигурация > Система > WWW

Порт на сървъра
Стандартният порт 443 не трябва да се използва за отдалечено управление, тъй като той винаги се сканира при автоматични атаки. Често използваните алтернативни портове (напр. 8443) също не са идеални.
Пренасочване на HTTP към HTTPS
Всички HTTP повиквания към графичния потребителски интерфейс се пренасочват към HTTPS. Внимание. Тази настройка не трябва да се активира, ако се използва уеб удостоверяване. Във всички останали случаи тази опция трябва да бъде разрешена.

Контрол на административните услуги
Тук можете да зададете кой може да има администраторски достъп до защитната стена. Най-добре би било да ограничите достъпа до отделни IP адреси. Само IP адресите са разрешени като обекти с адреси. Като последно правило (тук, правило 5) трябва да се създаде правило ALL/ALL/deny (Всичко/всичко/отказ). Трябва да се внимава при създаването на правилото, за да не се блокира достъпът до него. Следователно правилата за приемане трябва да бъдат създадени преди последното правило за отричане да бъде създадено.

Контрол на потребителските услуги
Контролът на потребителските услуги определя кои клиенти могат да се удостоверяват пред защитната стена.
Правилото е от значение за SSL-VPN, 2-FA, VPN Configuration Provisioning и WEB-Authentication.
Ако то не се използва, може да се зададе и правило за отказ.
Удостоверяване на клиентски сертификати
Ако опцията Удостоверяване на клиентски сертификат е активирана, клиентът трябва да се оторизира с валиден сертификат. В противен случай връзката ще бъде отказана. Това се отнася за достъп чрез HTTPS и SSL VPN. Конфигурация на VPN_Профилиране със SecuExtender не работи, ако тази опция е разрешена. Обаче извикването на прозореца 2FA все още е възможно без сертификат.

За да може защитната стена да се довери на даден сертификат, трябва да бъде инсталирана веригата на доверие на сертифициращия орган. Обикновено тя включва основен и междинен сертификат. Защитната стена се доверява на всеки сертификат с валидна верига от сертификати, както и на собствените си самоподписани сертификати. Трябва да се отбележи, че някои браузъри отхвърлят самоподписаните сертификати по принцип (понастоящем това са браузърите, базирани на Firefox). Не е необходимо клиентският сертификат да бъде инсталиран на защитната стена.

Конфигурация > Обект > Сертификат > Доверени сертификати

4. Услуги за отдалечено управление

Configuration (Конфигурация) > System (Система)
Има няколко услуги на защитната стена, които са рядко или никога не са необходими. Тези услуги могат да бъдат напълно деактивирани.

SSH
Например тази услуга може да се използва, когато промените в конфигурацията се извършват с автоматичен скрипт. Ако SSH не се използва редовно за администриране, услугата може да бъде деактивирана. Уеб конзолата също може да се използва вместо SSH за въвеждане на CLI.

TELNET
Вповечето случаи не е необходима и може да бъде деактивирана.

FTP
Чрез FTP може например да се актуализира фърмуерът или да се изтеглят конфигурационни файлове. FTP трябва да бъде активиран, ако се използва HA-Pro. Ако случаят не е такъв, FTP може да бъде деактивиран. Ако услугата е необходима спорадично, тя може да бъде активирана временно.
SNMPTУслугата е необходима за наблюдение на мрежата и се изисква за решения като PRTG. Ако мрежата не се наблюдава, услугата може да се деактивира.
ZON
Позволява обмен на информация със съседни устройства (модел, име, фърмуер, MAC адрес, IP адрес) чрез LLDP, както и със софтуера ZON на Zyxel в същата локална мрежа. Услугата не е необходима за редовна работа.

VPN

IPSec Site-to-Site VPN
Когато използвате тунели от сайт към сайт, трябва да се въведе адрес на партньорски шлюз, когато е възможно. Ако отдалеченият сайт има динамичен IP адрес, може да се използва и име DynDNS. DynDNS име може да се използва и ако отдалеченият сайт е зад NAT/CG-NAT. В този случай е важно връзката да се установи от отдалечената страна и услугата DynDNS да синхронизира публичния IP адрес.

За удостоверяване на автентичността е по-добре да се използва сертификат, отколкото PSK. Трябва да се има предвид следното:
1. Използваният сертификат може да бъде самоподписан сертификат, но трябва да бъде съхранен на отдалечената страна в "Доверени сертификати".
2. И от двете страни се създава собствен сертификат
3. Типът на локалния идентификатор се взема от сертификата и трябва да бъде въведен идентично с идентификатора на партньора от другата страна.
Препоръката за максимален срок на живот на SA е 86400 секунди в VPN шлюза и 14400 секунди във VPN връзката.
5. следните настройки се препоръчват като минимум за VPN криптиране: AES256 / SHA256 / DH15. Това се отнася както за VPN шлюза, така и за VPN връзката.
Разширеният протокол за удостоверяване на автентичността е възможен и за тунелите от сайт до сайт. Регистрираният потребител обаче не е вписан в защитната стена, когато се установява връзката.

IPSec VPN от клиент до сайт
За VPN от клиент към сайт се препоръчва IKEv2 със сертификат и Extended Authentication Protocol.

Конфигурационният полезен товар е задължителен във VPN връзката.

След установяване на връзката клиентът се регистрира в защитната стена с потребителя. За всеки администраторски достъп до защитната стена съответният администраторски потребител може по този начин да бъде съхранен в контрола на политиката.

L2TP-VPN

Използването на L2TP VPN не се препоръчва. Вместо това може да се използва IKEv2.

SSL VPN
Поради проблеми с производителността и възможни проблеми със сигурността, SSL VPN не се препоръчва. Въпреки това, тъй като тя е популярна поради лесното конфигуриране, трябва да се има предвид следното:

Конфигурация > VPN > SSL VPN > Глобална настройка

Използването на отделен порт за SSL VPN е задължително. При никакви обстоятелства не трябва да се използва порт 443.

Сигурността се повишава значително чрез използване на сертификат за удостоверяване. Конфигурацията е описана в "Дистанционно управление чрез HTTPS > Удостоверяване на клиентски сертификат".

В Policy Control (Контрол на политиката) е препоръчително да ограничите Source IP (IP на източника) за достъпа от WAN към ZyWALL за услугата Wiz_SSLVPN. Поне до GeoIP, а по-добре до FQDN или IP адрес.

Също така администраторският достъп до защитната стена от зоната SSL-VPN може да бъде ограничен до потребителя admin. Това е възможно, тъй като потребителят вече е влязъл в защитната стена по време на настройката на тунела.

Обикновените потребители не се нуждаят от достъп до защитната стена от зоната SSL VPN. Достатъчно е тук да бъдат разрешени типични услуги, като например DNS.

5. Двуфакторно удостоверяване

За администраторския достъп се препоръчва двуфакторна автентикация, за предпочитане с Google Authenticator.
Настройката за 2FA трябва да се извърши поотделно за всеки потребител. Препоръчва се методът Google Authenticator. Обърнете внимание, че потребителите, които нямат настроено 2FA, все пак могат да влязат в системата без допълнителна автентикация. Поради тази причина 2FA предлага само ограничена защита.

2FA kann auch für VPN-Access aktiviert werden.

Zur Authentifizierung wird immer ein eigener Port verwendet (Objekt Wiz_2FA).

Es stehen auch verschieden Methoden zur Verfügung, wie ein Link gesendet werden soll. Schlussendlich wird jedoch bei allen Methoden ein Link auf das WEB-GUI aufgerufen.

Da das WEB-GUI für 2FA aus dem WAN erreichbar sein muss, besteht hier auch ein potenzielles Angriffsrisiko. Aus diesem Grund ist diese Funktion mit Vorsicht zu geniessen.

Как да настроите двуфакторното удостоверяване е описано в друга наша статия:

Двуфакторно удостоверяване с Google Authenticator за достъп на администратора

6. Дневници за предупреждения

За някои опции може да е полезно да настроите дневник за предупреждения. В този случай може да се задейства имейл известие незабавно при възникване на събитие. Това има смисъл, например, когато администратор влезе в системата, особено за защитни стени, които се наблюдават само на нередовни интервали.

Конфигурация > Дневник и отчет > Настройки на дневника

7. Автоматични актуализации на фърмуера

Винаги трябва да се полагат грижи, за да се гарантира, че фърмуерът на защитната стена е актуален. За системи, които се поддържат активно, актуализациите могат да се извършват ръчно. В действителност обаче често се случва това да се пренебрегва и защитни стени с известни уязвимости в сигурността да не се актуализират за дълъг период от време.
Особено в среди от този тип се препоръчва да се активират автоматичните актуализации от съображения за сигурност.

Поддръжка > Файлов мениджър > Управление на фърмуера

8. Защита на чувствителни данни

От версия 5.35 на фърмуера паролите могат да се криптират с потребителски ключ вместо с алгоритъма по подразбиране. Другите пароли все още използват метода по подразбиране. Функцията също така предпазва от четене на потребителски пароли от конфигурационни файлове с помощта на хакерски инструменти.

Поддръжка > Мениджър на файлове > Конфигурационен файл > Конфигурация > Защита на чувствителни данни

Да предположим, че файлът е преинсталиран на защитна стена. Това е възможно само с помощта на ключа.