Как да конфигурирате защитна стена за вашия cPanel хостинг

Защитаването на cPanel сървър без правилно конфигурирана защитна стена е като да оставите входната врата на центъра за данни незаключена. ConfigServer Security & Firewall (CSF) е де факто стандартът за укрепване на cPanel и WHM среди — той се интегрира директно в интерфейса на WHM, обгръща iptables (или nftables при по-нови ядра) и се доставя с придружаващ демон, наречен Login Failure Daemon (LFD), който се занимава с откриване на прониквания в реално време. Това ръководство преминава през пълно, производствено внедряване на CSF: инсталация, архитектура на правила, усъвършенствано смекчаване на заплахи и текущ работен процес по поддръжка.

Независимо дали използвате VPS с cPanel или пълноценен Dedicated сървър, принципите на конфигурация са идентични. Разликата е, че на dedicated машина имате изключителен достъп до ядрото, което означава, че по-агресивните функции на CSF за проследяване на връзки и защита от SYN-flood могат да бъдат натоварени повече, без да засягат съседните наематели.

Защо софтуерната защитна стена не е по избор на cPanel сървъри

cPanel излага голяма повърхност за атака по дизайн. Стандартната инсталация отваря десетки портове за услуги — WHM (2086/2087), cPanel (2082/2083), FTP (21), mail submission (587), IMAP (993), POP3 (995) и други. Всеки отворен порт е потенциален вектор за влизане. Без филтър за пакети с проследяване на състоянието пред тези услуги:

• Атаките с груба сила срещу SSH, FTP и уеб поща успяват безшумно
• Ботове за пълнене с идентификационни данни удрят крайните точки xmlapi и cpsrvd
• DDoS трафикът, базиран на усилване, насища NIC преди приложният слой да може да реагира
• Компрометирани акаунти за споделен хостинг могат да се разпространят странично из сървъра

Хардуерна защитна стена на мрежовия периметър помага, но не може да вижда контекста на приложния слой — тя не знае, че даден IP е неуспешно влязъл 20 пъти подред в IMAP за 60 секунди. CSF + LFD работи на ниво хост и реагира точно на такъв вид поведенчески сигнал.

CSF срещу другите опции за защитна стена на cPanel

CSF печели по всяка ос, която има значение за cPanel среда. Единствената причина да изберете firewalld или ufw е ако използвате стек без cPanel и предпочитате по-лек инструмент.

Стъпка 1: Контролен списък преди инсталацията

Преди да докоснете дори една команда, изпълнете тези проверки. Пропускането им е начинът, по който администраторите случайно се заключват извън производствените сървъри.

Проверете достъпа си извън обхвата. Потвърдете, че имате достъп до конзолата на вашия хостинг доставчик (KVM over IP, IPMI или уеб-базирана VNC конзола). Ако CSF блокира вашия IP по време на тестване, достъпът до конзолата е вашият път за възстановяване.

Запишете вашия IP адрес за управление. Изпълнете следното от вашата локална машина:

curl -4 ifconfig.me

Ще добавите този IP в белия списък на CSF преди да активирате режима на прилагане.

Проверете текущото състояние на iptables:

iptables -L -n --line-numbers

Ако друг инструмент за защитна стена (APF, firewalld) вече е активен, спрете го и го деактивирайте преди инсталирането на CSF, за да предотвратите конфликти на правила.

Потвърдете, че Perl е инсталиран (CSF е базиран на Perl):

perl -v

На прясна система CentOS/AlmaLinux/CloudLinux, Perl присъства по подразбиране. При минимални инсталации на Ubuntu, инсталирайте го с apt install perl.

Стъпка 2: Инсталиране на CSF на вашия cPanel сървър

Свържете се с вашия сървър като root чрез SSH:

ssh root@YOUR_SERVER_IP

Изтеглете, разархивирайте и стартирайте инсталатора:

cd /usr/src
wget https://download.configserver.com/csf.tgz
tar -xzf csf.tgz
cd csf
sh install.sh

Инсталаторът регистрира CSF като системна услуга, инсталира плъгина за WHM и поставя основния конфигурационен файл на /etc/csf/csf.conf.

Стартирайте вградената проверка на зависимостите, за да потвърдите, че всички необходими Perl модули са налични:

perl /usr/local/csf/bin/csftest.pl

Всеки ред, маркиран с FATAL, трябва да бъде разрешен преди да продължите. Редовете, маркирани с WARN, са незадължителни функции — прегледайте ги, но те няма да попречат на функционирането на CSF.

Проверете инсталираната версия:

csf -v

Стъпка 3: Основна конфигурация в /etc/csf/csf.conf

Отворете основния конфигурационен файл в предпочитания от вас редактор:

nano /etc/csf/csf.conf

Файлът е обилно коментиран. Следните директиви имат най-голямо въздействие върху сигурността и трябва да бъдат прегледани при всяко ново внедряване.

Режим на тестване

Когато CSF е инсталиран за първи път, TESTING = "1" е зададен по подразбиране. В този режим LFD не стартира и не се прилагат блокирания — правилата се зареждат, но са временни. Не деактивирайте режима на тестване, докато не сте добавили вашия IP за управление в белия списък и не сте валидирали всички правила за портове.

TESTING = "0"   # Set this only after full validation

Списъци с разрешени входящи и изходящи портове

TCP_IN и TCP_OUT определят кои TCP портове са разрешени във всяка посока. Минималният, но функционален cPanel сървър се нуждае от:

TCP_IN = "20,21,22,25,53,80,110,143,443,465,587,993,995,2077,2078,2082,2083,2086,2087,2095,2096"
TCP_OUT = "20,21,22,25,53,80,110,113,443,587,993,995"
UDP_IN = "20,21,53"
UDP_OUT = "20,21,53,113,123"

Критична оперативна бележка: Порт 2087 е WHM SSL. Порт 2083 е cPanel SSL. Ако премахнете тези от TCP_IN преди да добавите вашия IP в белия списък, ще загубите достъп до контролния панел незабавно. Порт 123 (UDP изходящ) е NTP — премахването му нарушава синхронизацията на времето, което се отразява каскадно върху валидирането на SSL сертификати и отхвърлянето на доставка на поща.

Затворете всеки порт, който не е в активна употреба. Изпълнете ss -tlnp, за да проверите какво всъщност слуша, преди да финализирате този списък.

Добавяне на вашия IP за управление в белия списък

Добавете вашия IP в /etc/csf/csf.allow преди да деактивирате режима на тестване:

echo "YOUR.MANAGEMENT.IP # My office IP" >> /etc/csf/csf.allow

Алтернативно, използвайте директно командата CSF:

csf -a YOUR.MANAGEMENT.IP "Management workstation"

IP адресите в белия списък заобикалят всички блокирания на LFD и всички правила за ограничаване на скоростта. Поддържайте този списък минимален — всеки запис е постоянно изключение от вашата политика за сигурност.

Блокиране на известни злонамерени IP адреси

Постоянните блокирания отиват в /etc/csf/csf.deny:

csf -d MALICIOUS.IP.ADDRESS "Confirmed scanner"

За масово импортиране от канали за разузнаване на заплахи (Spamhaus DROP, Emerging Threats и др.), добавете CIDR директно към /etc/csf/csf.deny и презаредете:

csf -r

Стъпка 4: Конфигуриране на Login Failure Daemon (LFD)

LFD е компонентът за поведенческо откриване на прониквания на CSF. Той следи системните лог файлове в реално време, брои неуспешните удостоверявания на изходен IP и задейства временно блокиране, когато се надхвърли праг. Това е вашата основна защита срещу атаки с груба сила върху идентификационни данни.

Ключови директиви на LFD в csf.conf:

Граничен случай, който трябва да знаете: Ако вашият сървър е зад NAT шлюз или споделен офис рутер, множество легитимни потребители споделят един външен IP. Задаването на LF_TRIGGER твърде ниско ще блокира целия ви офис след няколко грешно въведени пароли. Или повишете прага, или добавете офис IP в белия списък в csf.allow.

LFD също наблюдава за подозрителни процеси, събития за наблюдение на директории и откриване на промени в файлове (функциите LF_DIRWATCH и LF_INTEGRITY). Активирайте LF_INTEGRITY, за да откривате неоторизирани промени в системните двоични файлове:

LF_INTEGRITY = "3600"   # Check every hour

Стъпка 5: Разширени функции за смекчаване на заплахи

Защита от SYN Flood

SYN flood атаките изчерпват таблицата за TCP връзки, като изпращат големи обеми SYN пакети без завършване на ръкостискането. Активирайте вградената защита на CSF:

SYNFLOOD = "1"
SYNFLOOD_RATE = "100/s"
SYNFLOOD_BURST = "150"

Тези стойности позволяват 100 нови SYN пакета в секунда с допустимо изблик от 150 преди правилото да се задейства. Настройте тези числа въз основа на вашия легитимен пиков трафик — сайт за електронна търговия по време на светкавична разпродажба може да се нуждае от по-високи стойности на изблика.

Проследяване на връзки

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

CT_LIMIT = "300"
CT_INTERVAL = "30"
CT_BLOCK_TIME = "1800"
CT_SKIP_LOCAL = "1"

CT_SKIP_LOCAL предотвратява броенето на localhost и loopback връзките към лимита — от съществено значение на сървъри, където cPanel демоните комуникират вътрешно по TCP.

Откриване на сканиране на портове

CSF може да открива и блокира хостове, които сондират множество портове в кратък прозорец:

PS_INTERVAL = "300"
PS_LIMIT = "10"
PS_BLOCK_TIME = "3600"
PS_PERMANENT = "0"

IP, който достигне 10 или повече затворени порта в рамките на 300 секунди, се блокира за един час. Задайте PS_PERMANENT = "1" само ако сте уверени, че легитимните ви потребители никога случайно няма да задействат това — някои пощенски клиенти и инструменти за наблюдение сондират множество портове по време на договаряне на връзката.

Блокиране на ниво държава

Ако вашето приложение няма легитимни потребители в определени високорискови региони, блокирането на ниво държава драматично намалява шума в логовете ви и натоварването на LFD. Редактирайте csf.conf:

CC_DENY = "CN,RU,KP,NG"
CC_ALLOW = ""

Кодовете на държавите следват стандарта ISO 3166-1 alpha-2. CSF изтегля GeoIP данни автоматично. Бъдете прецизни тук — блокирането на цели държави е груб инструмент. По-добър подход за повечето внедрявания е CC_ALLOW (добавяне в белия списък само на държавите, където се намират вашите потребители) в комбинация с CC_ALLOW_PORTS, за да ограничите достъпа, базиран на държава, само до конкретни портове.

Ограничения за изходящ SMTP

Компрометирани WordPress инсталации и уязвими скриптове често се използват като релета за спам. CSF може да ограничи изходящия SMTP само до оторизирани пощенски процеси:

SMTP_BLOCK = "1"
SMTP_ALLOWUSER = "mailman"
SMTP_ALLOWGROUP = "mail"

Това блокира всички изходящи връзки на порт 25, с изключение на процеси, работещи като посочения потребител или група. Легитимната доставка на поща чрез вашия MTA (Exim на cPanel) не е засегната, тъй като Exim работи като групата mail. Тази единична директива елиминира цял клас злоупотреба със спам от компрометирани акаунти.

Ако имате нужда от изходяща пощенска инфраструктура от професионален клас заедно с вашия хостинг, помислете за сдвояване на вашия сървър с dedicated решение за Email Hosting за транзакционна и маркетингова поща.

Стъпка 6: Прилагане и тестване на конфигурацията

След като прегледате всички директиви, презаредете CSF, за да приложите промените без пълно рестартиране:

csf -r

За пълно рестартиране на CSF и LFD:

csf -ra

Проверете текущото състояние и броя на активните правила:

csf -l

Проверете дали LFD работи:

systemctl status lfd

Тествайте от външен IP (не вашия IP за управление в белия списък), че блокирането на портове работи както се очаква. Използвайте nmap от отделна машина:

nmap -sS -p 1-65535 YOUR_SERVER_IP

Само портовете, изрично изброени в TCP_IN, трябва да се показват като отворени. Всички останали трябва да върнат filtered.

Деактивирайте режима на тестване само след като тази валидация премине успешно:

# In /etc/csf/csf.conf, set TESTING = "0", then:
csf -r

Стъпка 7: Конфигурация чрез WHM GUI

За администратори, които предпочитат графичен интерфейс, CSF се интегрира напълно в WHM. Навигирайте до WHM > Plugins > ConfigServer Security & Firewall. Оттук можете да:

• Преглеждате живия списък с блокирания и ръчно да деблокирате IP адреси
• Добавяте временни и постоянни записи за разрешаване/отказване
• Задействате проверка на конфигурацията, която валидира синтаксиса на csf.conf
• Преглеждате логовете на LFD в странициран, търсещ интерфейс
• Стартирате инструмента за синхронизация на клъстер при управление на множество сървъри

Интерфейсът на WHM е особено полезен за персонала по поддръжка, който трябва да деблокира легитимен клиентски IP без SSH достъп. Предоставяйте избирателно достъп до плъгина CSF на WHM акаунти на препродавачи — не всеки препродавач се нуждае от възможност за управление на защитната стена.

Стъпка 8: Наблюдение, анализ на логове и поддръжка

Наблюдение на логове в реално време

LFD записва събития за блокиране в /var/log/lfd.log. Следете го по време на активен инцидент:

tail -f /var/log/lfd.log

Собственият лог за активност на CSF е на /var/log/csf.log. За обобщение на най-често блокираните IP адреси през последните 24 часа:

grep "Blocked" /var/log/lfd.log | awk '{print $NF}' | sort | uniq -c | sort -rn | head -20

Имейл известия

Конфигурирайте LFD да изпраща известия до вашия административен адрес:

LF_ALERT_TO = "admin@yourdomain.com"
LF_ALERT_FROM = "lfd@yourdomain.com"

Активирайте конкретни типове известия:

LF_EMAIL_ALERT = "1"      # Block alerts
LT_EMAIL_ALERT = "1"      # Login tracking alerts
RT_EMAIL_ALERT = "1"      # Resource usage alerts

Избягвайте активирането на всеки тип известие на натоварен сървър — умората от известия кара администраторите да започнат да игнорират уведомленията, което напълно осуетява целта.

Актуализиране на CSF

CSF пуска актуализации често. Стартирайте вградения инструмент за актуализация:

csf -u

Това изтегля най-новата версия, запазва вашите конфигурационни файлове и рестартира услугата. Планирайте това в седмично cron задание:

0 3 * * 0 /usr/sbin/csf -u >> /var/log/csf_update.log 2>&1

Интегриране с cPHulk

cPanel се доставя със собствен инструмент за защита от груба сила, наречен cPHulk. Едновременното стартиране на cPHulk и LFD създава излишни блокирания и може да причини объркване по време на реакция при инциденти. Препоръчителният подход: деактивирайте cPHulk и разчитайте изключително на LFD, който е по-конфигурируем и се интегрира с унифицирания списък с блокирания на CSF.

Деактивирайте cPHulk чрез WHM под Security Center > cPHulk Brute Force Protection.

Архитектура на защитната стена за среди с множество сървъри

Ако управлявате множество cPanel сървъри — обичаен модел с клъстери за VPS Hosting или основен уеб сървър, сдвоен с отделен сървър за бази данни — функцията за синхронизация на клъстер на CSF ви позволява да разпространявате списъци с блокирания едновременно на всички възли.

Конфигурирайте членовете на клъстера в /etc/csf/csf.conf:

CLUSTER_MASTER = "PRIMARY_SERVER_IP"
CLUSTER_SENDTO = "SECONDARY_SERVER_IP"
CLUSTER_RECVFROM = "PRIMARY_SERVER_IP"
CLUSTER_KEY = "your_shared_secret_key"

Когато LFD блокира IP на основния сървър, блокирането автоматично се изпраща до всички членове на клъстера в рамките на секунди. Това е особено ценно, когато скенер, сондиращ вашия уеб сървър, също се опитва да извърши SSH груба сила на вашия възел за бази данни.

За среди с висок трафик или GPU-интензивни натоварвания, работещи заедно с уеб услуги, инфраструктурата за GPU Hosting се възползва от същия подход за укрепване с CSF — конфигурацията на защитната стена е идентична, но стойностите на CT_LIMIT обикновено трябва да бъдат по-високи, за да се поберат легитимните паралелни API връзки.

Съображения за SSL и сигурност на портовете

Защитната стена контролира достъпа до портове, но не валидира криптографската цялост на връзките на тези портове. Уверете се, че всяка услуга, изложена чрез правилата на вашата защитна стена, е защитена и с валиден SSL/TLS сертификат. Отворен порт 443 с изтекъл или самоподписан сертификат е риск за фишинг и MITM.

Сдвоете конфигурацията на вашата защитна стена с правилно издадени сертификати от доверен CA. AlexHost предоставя SSL сертификати, които се интегрират директно с работния процес AutoSSL на cPanel, гарантирайки, че вашите изложени HTTPS крайни точки са криптографски надеждни.

Чести грешки и как да ги избегнете

Заключване на себе си по време на първоначалната настройка. Винаги добавяйте вашия IP в белия списък в csf.allow преди да зададете TESTING = "0". Винаги потвърждавайте достъпа до конзолата преди да правите промени в прилагането.

Блокиране на собствените вътрешни услуги на cPanel. cPanel демоните комуникират по localhost и понякога по основния IP на сървъра. CT_SKIP_LOCAL = "1" и внимателният преглед на TCP_OUT предотвратяват самопричинени прекъсвания на услугата.

Прекалено агресивен LF_DURATION при споделен хостинг. Ако легитимни потребители споделят NAT IP с нападатели, 24-часово блокиране наказва невинни клиенти. Използвайте LF_DURATION = "3600" и LF_PERMBLOCK_COUNT = "4", за да ескалирате само повторните нарушители до постоянни забрани.

Забравяне да отворите портовете на агента за наблюдение. Ако използвате външна услуга за наблюдение (Zabbix, Nagios, Datadog), нейният агент изисква отворен входящ порт. Добавете го към TCP_IN и добавете IP на сървъра за наблюдение в белия списък в csf.allow.

Нетестване на изходящи правила. Администраторите се фокусират върху входящия TCP_IN, но пренебрегват TCP_OUT. Прекалено ограничителните изходящи правила нарушават системата за актуализации на cPanel, подновяванията на сертификати на Let’s Encrypt (порт 80 изходящ към ACME сървъри) и отдалечените MySQL връзки.

Стартиране на CSF на сървър с Cloudflare проксиране. Когато трафикът преминава през Cloudflare, изходният IP, видян от CSF, е IP на Cloudflare edge възел, а не реалният IP на посетителя. Блокирането на Cloudflare IP блокира целия трафик през този edge възел. Използвайте файла csf.allow, за да добавите в белия списък публикуваните IP диапазони на Cloudflare и конфигурирайте вашето приложение да чете заглавката CF-Connecting-IP за реалните IP адреси на посетителите.

Матрица за технически решения: Избор на профил за конфигурация на CSF

Ключови изводи: Контролен списък за готовност за производство

Преди да считате вашето внедряване на CSF за готово за производство, проверете всеки елемент по-долу:

• IP за управление е наличен в /etc/csf/csf.allow и потвърден с csf -g YOUR.IP

TESTING = "0" е зададен и csf -r е изпълнен
TCP_IN съдържа само портове с активни, умишлени услуги — проверено срещу ss -tlnp

SMTP_BLOCK = "1" е активиран, освен ако сървърът не е dedicated пощенско реле
LFD работи — потвърдено с systemctl status lfd

LF_PERMBLOCK_COUNT и LF_PERMBLOCK_INTERVAL са конфигурирани за ескалиране на повторните нарушители
CT_LIMIT е зададен и настроен спрямо очакваните пикови едновременни връзки
SYNFLOOD = "1" е активиран с подходящи за обема на трафика ви стойности на скоростта
Имейл известията са конфигурирани и е получено тестово известие
cPHulk е деактивиран в WHM, за да се предотвратят конфликти с LFD
Планирано е седмично cron задание csf -u

ЧЗВ

Каква е разликата между CSF и хардуерна защитна стена и нуждая ли се от двете?

Хардуерната защитна стена работи на мрежовия периметър и филтрира трафика преди да достигне NIC на вашия сървър. CSF работи на ниво ОС и добавя приложно-осъзнато, поведенческо откриване, което хардуерните защитни стени не могат да осигурят — като блокиране на IP след повторни неуспешни влизания в cPanel. В производствена среда двата слоя се допълват. Хардуерното филтриране намалява обемния DDoS товар; CSF се справя с целенасочени опити за проникване.

Как да деблокирам IP, който CSF е постоянно забранил?

Изпълнете csf -dr BLOCKED.IP.ADDRESS, за да го премахнете от списъка с откази, след това csf -r, за да презаредите правилата. Алтернативно, използвайте интерфейса на плъгина CSF в WHM под „Unblock an IP.” За да предотвратите повторно блокиране, добавете IP в csf.allow с csf -a IP.ADDRESS "reason".

Ще пречи ли CSF на подновяванията на сертификати на Let’s Encrypt / AutoSSL?

Само ако порт 80 изходящ е блокиран в TCP_OUT или ако IP адресите на сървъра за валидиране на Let’s Encrypt са случайно в csf.deny. Уверете се, че порт 80 е в TCP_IN (за отговори на HTTP-01 предизвикателства) и TCP_OUT (за комуникация с ACME сървъра). Ако подновяванията се провалят след инсталацията на CSF, проверете csf.deny за IP диапазони на Let’s Encrypt и прегледайте /var/log/lfd.log за блокирани изходящи връзки.

Как да тествам безопасно ново правило на CSF без риск от заключване?

Временно активирайте отново режима на тестване, като зададете TESTING = "1" в csf.conf и изпълните csf -r. В режим на тестване правилата се зареждат, но не се прилагат, и LFD не стартира. Валидирайте промените си, след това задайте TESTING = "0" и презаредете. Винаги потвърждавайте достъпа до конзолата преди да превключите обратно към режим на прилагане.

Защитава ли CSF срещу атаки на приложния слой като SQL инжекция или XSS?

Не. CSF работи на мрежовия и транспортния слой (L3/L4) и няма видимост в полезните товари на HTTP заявките. Атаките на приложния слой изискват Web Application Firewall (WAF) като ModSecurity с OWASP Core Rule Set, който се интегрира с Apache и Nginx на cPanel сървъри. CSF и ModSecurity се допълват — CSF се справя с заплахи на мрежово ниво, докато ModSecurity се справя с атаки на HTTP ниво. LFD може да бъде конфигуриран да блокира IP адреси, които многократно задействат правила на ModSecurity, чрез директивата LF_MODSEC.