Jak skonfigurować zaporę sieciową dla hostingu cPanel

Zabezpieczenie serwera cPanel bez odpowiednio skonfigurowanego firewalla jest jak pozostawienie otwartych drzwi wejściowych centrum danych. ConfigServer Security & Firewall (CSF) jest de facto standardem dla wzmacniania środowisk cPanel i WHM — integruje się bezpośrednio z interfejsem WHM, opakowuje iptables (lub nftables na nowszych jądrach) i jest dostarczany z towarzyszącym demonem o nazwie Login Failure Daemon (LFD), który obsługuje wykrywanie włamań w czasie rzeczywistym. Ten przewodnik przeprowadza przez kompletne, produkcyjne wdrożenie CSF: instalację, architekturę reguł, zaawansowane łagodzenie zagrożeń i bieżący przepływ pracy konserwacyjnej.

Niezależnie od tego, czy korzystasz z VPS z cPanel czy pełnego Serwera Dedykowanego, zasady konfiguracji są identyczne. Różnica polega na tym, że na dedykowanej maszynie masz wyłączny dostęp do jądra, co oznacza, że bardziej agresywne funkcje śledzenia połączeń i ochrony przed zalewaniem SYN w CSF mogą być mocniej wykorzystywane bez wpływu na sąsiednich najemców.

Dlaczego programowy firewall nie jest opcjonalny na serwerach cPanel

cPanel z założenia eksponuje dużą powierzchnię ataku. Domyślna instalacja otwiera dziesiątki portów usług — WHM (2086/2087), cPanel (2082/2083), FTP (21), przesyłanie poczty (587), IMAP (993), POP3 (995) i inne. Każdy otwarty port jest potencjalnym wektorem wejścia. Bez stanowego filtra pakietów przed tymi usługami:

• Ataki brute-force na SSH, FTP i webmail kończą się sukcesem po cichu
• Boty do upychania danych uwierzytelniających atakują punkty końcowe xmlapi i cpsrvd
• Ruch DDoS oparty na amplifikacji nasyca kartę sieciową, zanim warstwa aplikacji zdąży zareagować
• Skompromitowane konta hostingu współdzielonego mogą przemieszczać się bocznie po serwerze

Sprzętowy firewall na obrzeżu sieci pomaga, ale nie może widzieć kontekstu warstwy aplikacji — nie wie, że adres IP nie przeszedł 20 kolejnych logowań IMAP w ciągu 60 sekund. CSF + LFD działa na poziomie hosta i reaguje dokładnie na tego rodzaju sygnały behawioralne.

CSF vs. inne opcje firewalla dla cPanel

CSF wygrywa na każdej osi, która ma znaczenie dla środowiska cPanel. Jedynym powodem, aby wybrać firewalld lub ufw, jest sytuacja, gdy korzystasz ze stosu bez cPanel i preferujesz lżejsze narzędzie.

Krok 1: Lista kontrolna przed instalacją

Przed wykonaniem jakiegokolwiek polecenia wykonaj te sprawdzenia. Ich pominięcie jest przyczyną, dla której administratorzy przypadkowo blokują sobie dostęp do serwerów produkcyjnych.

Zweryfikuj swój dostęp poza pasmem. Potwierdź, że masz dostęp do konsoli swojego dostawcy hostingu (KVM over IP, IPMI lub konsolę VNC opartą na przeglądarce). Jeśli CSF zablokuje Twój adres IP podczas testowania, dostęp do konsoli jest Twoją ścieżką odzyskiwania.

Zapisz swój adres IP zarządzania. Uruchom następujące polecenie ze swojego lokalnego komputera:

curl -4 ifconfig.me

Ten adres IP zostanie umieszczony na białej liście w CSF przed włączeniem trybu egzekwowania.

Sprawdź istniejący stan iptables:

iptables -L -n --line-numbers

Jeśli inne narzędzie firewalla (APF, firewalld) jest już aktywne, zatrzymaj je i wyłącz przed instalacją CSF, aby zapobiec konfliktom reguł.

Potwierdź, że Perl jest zainstalowany (CSF jest oparty na Perlu):

perl -v

Na świeżym systemie CentOS/AlmaLinux/CloudLinux Perl jest domyślnie obecny. Na minimalnych kompilacjach Ubuntu zainstaluj go za pomocą apt install perl.

Krok 2: Instalacja CSF na serwerze cPanel

Połącz się z serwerem jako root przez SSH:

ssh root@YOUR_SERVER_IP

Pobierz, rozpakuj i uruchom instalator:

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

Instalator rejestruje CSF jako usługę systemową, instaluje wtyczkę WHM i umieszcza główny plik konfiguracyjny w /etc/csf/csf.conf.

Uruchom wbudowane sprawdzenie zależności, aby potwierdzić, że wszystkie wymagane moduły Perl są obecne:

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

Każda linia oznaczona FATAL musi zostać rozwiązana przed kontynuowaniem. Linie oznaczone WARN to opcjonalne funkcje — przejrzyj je, ale nie uniemożliwią one działania CSF.

Zweryfikuj zainstalowaną wersję:

csf -v

Krok 3: Podstawowa konfiguracja w /etc/csf/csf.conf

Otwórz główny plik konfiguracyjny w preferowanym edytorze:

nano /etc/csf/csf.conf

Plik jest bogato opatrzony komentarzami. Następujące dyrektywy mają największy wpływ na bezpieczeństwo i muszą być przeglądane przy każdym nowym wdrożeniu.

Tryb testowy

Gdy CSF jest po raz pierwszy instalowany, TESTING = "1" jest ustawiony domyślnie. W tym trybie LFD nie uruchamia się i żadne blokady nie są egzekwowane — reguły są ładowane, ale tymczasowe. Nie wyłączaj trybu testowego, dopóki nie umieścisz swojego adresu IP zarządzania na białej liście i nie zwalidowasz wszystkich reguł portów.

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

Listy dozwolonych portów przychodzących i wychodzących

TCP_IN i TCP_OUT definiują, które porty TCP są dozwolone w każdym kierunku. Minimalny, ale funkcjonalny serwer cPanel potrzebuje:

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"

Krytyczna uwaga operacyjna: Port 2087 to WHM SSL. Port 2083 to cPanel SSL. Jeśli usuniesz je z TCP_IN przed umieszczeniem swojego adresu IP na białej liście, natychmiast utracisz dostęp do panelu sterowania. Port 123 (UDP wychodzący) to NTP — jego usunięcie powoduje przerwanie synchronizacji czasu, co kaskadowo prowadzi do błędów walidacji certyfikatów SSL i odrzuceń dostarczania poczty.

Zamknij każdy port, który nie jest aktywnie używany. Uruchom ss -tlnp, aby sprawdzić, co faktycznie nasłuchuje, przed sfinalizowaniem tej listy.

Umieszczanie adresu IP zarządzania na białej liście

Dodaj swój adres IP do /etc/csf/csf.allow przed wyłączeniem trybu testowego:

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

Alternatywnie użyj polecenia CSF bezpośrednio:

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

Adresy IP na białej liście omijają wszystkie blokady LFD i wszystkie reguły ograniczania szybkości. Utrzymuj tę listę minimalną — każdy wpis jest trwałym wyjątkiem od Twojej polityki bezpieczeństwa.

Blokowanie znanych złośliwych adresów IP

Trwałe blokady trafiają do /etc/csf/csf.deny:

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

W przypadku masowych importów z kanałów informacji o zagrożeniach (Spamhaus DROP, Emerging Threats itp.) dołącz CIDRy bezpośrednio do /etc/csf/csf.deny i przeładuj:

csf -r

Krok 4: Konfiguracja Login Failure Daemon (LFD)

LFD jest behawioralnym komponentem wykrywania włamań CSF. Śledzi pliki dziennika systemowego w czasie rzeczywistym, zlicza błędy uwierzytelniania na źródłowy adres IP i wyzwala tymczasową blokadę po przekroczeniu progu. Jest to Twoja podstawowa obrona przed atakami brute-force na dane uwierzytelniające.

Kluczowe dyrektywy LFD w csf.conf:

Przypadek brzegowy, który warto znać: Jeśli Twój serwer znajduje się za bramą NAT lub współdzielonym routerem biurowym, wielu legalnych użytkowników współdzieli jeden zewnętrzny adres IP. Ustawienie zbyt niskiego LF_TRIGGER zablokuje całe biuro po kilku literówkach. Albo podnieś próg, albo umieść adres IP biura na białej liście w csf.allow.

LFD monitoruje również podejrzane procesy, zdarzenia obserwowania katalogów i wykrywanie zmian plików (funkcje LF_DIRWATCH i LF_INTEGRITY). Włącz LF_INTEGRITY, aby wykrywać nieautoryzowane modyfikacje plików binarnych systemu:

LF_INTEGRITY = "3600"   # Check every hour

Krok 5: Zaawansowane funkcje łagodzenia zagrożeń

Ochrona przed zalewaniem SYN

Ataki zalewania SYN wyczerpują tablicę połączeń TCP, wysyłając duże ilości pakietów SYN bez zakończenia uzgadniania. Włącz wbudowane łagodzenie CSF:

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

Te wartości pozwalają na 100 nowych pakietów SYN na sekundę z dopuszczeniem serii 150 przed wyzwoleniem reguły. Dostosuj te liczby na podstawie swojego legalnego szczytowego ruchu — witryna e-commerce podczas wyprzedaży błyskawicznej może wymagać wyższych wartości serii.

Śledzenie połączeń

Śledzenie połączeń ogranicza całkowitą liczbę jednoczesnych połączeń z jednego adresu IP na wszystkich portach. Jest to skuteczne przeciwko atakom DDoS o niskiej szybkości i wyczerpaniu połączeń:

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

CT_SKIP_LOCAL zapobiega wliczaniu połączeń localhost i loopback do limitu — niezbędne na serwerach, gdzie demony cPanel komunikują się wewnętrznie przez TCP.

Wykrywanie skanowania portów

CSF może wykrywać i blokować hosty, które sondują wiele portów w krótkim oknie czasowym:

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

Adres IP, który trafi na 10 lub więcej zamkniętych portów w ciągu 300 sekund, zostaje zablokowany na jedną godzinę. Ustaw PS_PERMANENT = "1" tylko jeśli jesteś pewien, że Twoi legalni użytkownicy nigdy przypadkowo tego nie wyzwolą — niektórzy klienci poczty i narzędzia monitorujące sondują wiele portów podczas negocjacji połączenia.

Blokowanie na poziomie kraju

Jeśli Twoja aplikacja nie ma legalnych użytkowników w niektórych regionach wysokiego ryzyka, blokowanie na poziomie kraju dramatycznie redukuje szum w dziennikach i obciążenie LFD. Edytuj csf.conf:

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

Kody krajów są zgodne ze standardem ISO 3166-1 alfa-2. CSF automatycznie pobiera dane GeoIP. Bądź precyzyjny — blokowanie całych krajów to tępe narzędzie. Lepszym podejściem dla większości wdrożeń jest CC_ALLOW (umieszczenie na białej liście tylko krajów, w których znajdują się Twoi użytkownicy) w połączeniu z CC_ALLOW_PORTS, aby ograniczyć dostęp oparty na kraju tylko do określonych portów.

Ograniczenia wychodzącego SMTP

Skompromitowane instalacje WordPress i podatne skrypty są często używane jako przekaźniki spamu. CSF może ograniczyć wychodzący SMTP tylko do autoryzowanych procesów pocztowych:

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

Blokuje to wszystkie wychodzące połączenia na porcie 25, z wyjątkiem procesów działających jako określony użytkownik lub grupa. Legalne dostarczanie poczty przez Twój MTA (Exim na cPanel) nie jest zakłócone, ponieważ Exim działa jako grupa mail. Ta jedna dyrektywa eliminuje całą klasę nadużyć spamowych ze skompromitowanych kont.

Jeśli potrzebujesz profesjonalnej infrastruktury poczty wychodzącej obok swojego hostingu, rozważ połączenie serwera z dedykowanym rozwiązaniem Hostingu Poczty E-mail dla poczty transakcyjnej i marketingowej.

Krok 6: Stosowanie i testowanie konfiguracji

Po przejrzeniu wszystkich dyrektyw przeładuj CSF, aby zastosować zmiany bez pełnego restartu:

csf -r

Aby w pełni zrestartować zarówno CSF, jak i LFD:

csf -ra

Sprawdź bieżący status i liczbę aktywnych reguł:

csf -l

Zweryfikuj, czy LFD działa:

systemctl status lfd

Przetestuj z zewnętrznego adresu IP (nie z Twojego adresu IP zarządzania na białej liście), że blokowanie portów działa zgodnie z oczekiwaniami. Użyj nmap z oddzielnej maszyny:

nmap -sS -p 1-65535 YOUR_SERVER_IP

Tylko porty wyraźnie wymienione w TCP_IN powinny być widoczne jako otwarte. Wszystkie pozostałe powinny zwracać filtered.

Wyłącz tryb testowy dopiero po pomyślnym przejściu tej walidacji:

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

Krok 7: Konfiguracja GUI WHM

Dla administratorów preferujących interfejs graficzny, CSF integruje się w pełni z WHM. Przejdź do WHM > Wtyczki > ConfigServer Security & Firewall. Stąd możesz:

• Przeglądać aktywną listę blokad i ręcznie odblokowywać adresy IP
• Dodawać tymczasowe i trwałe wpisy zezwolenia/odmowy
• Uruchamiać sprawdzenie konfiguracji, które waliduje składnię csf.conf
• Przeglądać dzienniki LFD w paginowanym, przeszukiwalnym interfejsie
• Uruchamiać narzędzie synchronizacji klastra przy zarządzaniu wieloma serwerami

Interfejs WHM jest szczególnie przydatny dla personelu wsparcia, który musi odblokować legalny adres IP klienta bez dostępu SSH. Selektywnie przyznawaj kontom resellerów WHM dostęp do wtyczki CSF — nie każdy reseller potrzebuje możliwości zarządzania firewallem.

Krok 8: Monitorowanie, analiza dzienników i konserwacja

Monitorowanie dzienników w czasie rzeczywistym

LFD zapisuje zdarzenia blokowania do /var/log/lfd.log. Śledź go podczas aktywnego incydentu:

tail -f /var/log/lfd.log

Własny dziennik aktywności CSF znajduje się w /var/log/csf.log. Aby uzyskać podsumowanie najczęściej blokowanych adresów IP z ostatnich 24 godzin:

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

Alerty e-mail

Skonfiguruj LFD, aby wysyłał alerty na Twój adres administracyjny:

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

Włącz określone typy alertów:

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

Unikaj włączania każdego typu alertu na zajętym serwerze — zmęczenie alertami powoduje, że administratorzy zaczynają ignorować powiadomienia, co całkowicie niweczy cel.

Aktualizacja CSF

CSF często wydaje aktualizacje. Uruchom wbudowany aktualizator:

csf -u

Pobiera to najnowszą wersję, zachowuje pliki konfiguracyjne i restartuje usługę. Zaplanuj to w cotygodniowym zadaniu cron:

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

Integracja z cPHulk

cPanel jest dostarczany z własnym narzędziem ochrony przed brute-force o nazwie cPHulk. Jednoczesne uruchamianie zarówno cPHulk, jak i LFD tworzy redundantne blokady i może powodować zamieszanie podczas reagowania na incydenty. Zalecane podejście: wyłącz cPHulk i polegaj wyłącznie na LFD, który jest bardziej konfigurowalny i integruje się z ujednoliconą listą blokad CSF.

Wyłącz cPHulk przez WHM w Centrum bezpieczeństwa > Ochrona przed atakami brute-force cPHulk.

Architektura firewalla dla środowisk wieloserwerowych

Jeśli zarządzasz wieloma serwerami cPanel — powszechny wzorzec z klastrami Hostingu VPS lub głównym serwerem WWW połączonym z oddzielnym serwerem bazy danych — funkcja synchronizacji klastra CSF pozwala propagować listy blokad na wszystkich węzłach jednocześnie.

Skonfiguruj członków klastra w /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"

Gdy LFD zablokuje adres IP na głównym serwerze, blokada jest automatycznie przekazywana do wszystkich członków klastra w ciągu kilku sekund. Jest to szczególnie cenne, gdy skaner sondujący Twój serwer WWW próbuje również przeprowadzić atak brute-force SSH na węźle bazy danych.

W środowiskach o dużym ruchu lub obciążeniach intensywnie korzystających z GPU działających obok usług WWW, infrastruktura Hostingu GPU korzysta z tego samego podejścia do wzmacniania CSF — konfiguracja firewalla jest identyczna, ale wartości CT_LIMIT zazwyczaj muszą być wyższe, aby uwzględnić legalne równoległe połączenia API.

Kwestie bezpieczeństwa SSL i portów

Firewall kontroluje dostęp do portów, ale nie weryfikuje kryptograficznej integralności połączeń na tych portach. Upewnij się, że każda usługa eksponowana przez reguły firewalla jest również chroniona ważnym certyfikatem SSL/TLS. Otwarty port 443 z wygasłym lub samopodpisanym certyfikatem stanowi ryzyko phishingu i ataku MITM.

Połącz konfigurację firewalla z prawidłowo wydanymi certyfikatami od zaufanego CA. AlexHost zapewnia Certyfikaty SSL, które integrują się bezpośrednio z przepływem pracy AutoSSL cPanel, zapewniając kryptograficzną solidność Twoich eksponowanych punktów końcowych HTTPS.

Typowe pułapki i jak ich unikać

Blokowanie sobie dostępu podczas wstępnej konfiguracji. Zawsze umieszczaj swój adres IP na białej liście w csf.allow przed ustawieniem TESTING = "0". Zawsze potwierdzaj dostęp do konsoli przed wprowadzaniem zmian w egzekwowaniu.

Blokowanie własnych wewnętrznych usług cPanel. Demony cPanel komunikują się przez localhost i czasami przez główny adres IP serwera. CT_SKIP_LOCAL = "1" i staranne przeglądanie TCP_OUT zapobiegają samodzielnie spowodowanym zakłóceniom usług.

Zbyt agresywne LF_DURATION na hostingu współdzielonym. Jeśli legalni użytkownicy współdzielą adres IP NAT z atakującymi, 24-godzinna blokada karze niewinnych klientów. Używaj LF_DURATION = "3600" i LF_PERMBLOCK_COUNT = "4", aby eskalować tylko recydywistów do trwałych zakazów.

Zapominanie o otwieraniu portów agenta monitorującego. Jeśli korzystasz z zewnętrznej usługi monitorowania (Zabbix, Nagios, Datadog), jej agent wymaga otwartego portu przychodzącego. Dodaj go do TCP_IN i umieść adres IP serwera monitorującego na białej liście w csf.allow.

Brak testowania reguł wychodzących. Administratorzy skupiają się na przychodzącym TCP_IN, ale zaniedbują TCP_OUT. Zbyt restrykcyjne reguły wychodzące psują system aktualizacji cPanel, odnawianie certyfikatów Let’s Encrypt (port 80 wychodzący do serwerów ACME) i zdalne połączenia MySQL.

Uruchamianie CSF na serwerze z proxy Cloudflare. Gdy ruch przechodzi przez Cloudflare, źródłowy adres IP widziany przez CSF to adres IP węzła brzegowego Cloudflare, a nie rzeczywisty adres IP odwiedzającego. Zablokowanie adresu IP Cloudflare blokuje cały ruch przez ten węzeł brzegowy. Użyj pliku csf.allow, aby umieścić na białej liście opublikowane zakresy adresów IP Cloudflare i skonfiguruj swoją aplikację do odczytywania nagłówka CF-Connecting-IP dla rzeczywistych adresów IP odwiedzających.

Macierz decyzji technicznych: Wybór profilu konfiguracji CSF

Kluczowe wnioski: Lista kontrolna gotowości produkcyjnej

Przed uznaniem wdrożenia CSF za gotowe do produkcji, zweryfikuj każdy poniższy element:

• Adres IP zarządzania jest obecny w /etc/csf/csf.allow i potwierdzony za pomocą csf -g YOUR.IP

TESTING = "0" jest ustawiony i csf -r został uruchomiony
TCP_IN zawiera tylko porty z aktywnymi, zamierzonymi usługami — zweryfikowane względem ss -tlnp

SMTP_BLOCK = "1" jest włączony, chyba że serwer jest dedykowanym przekaźnikiem poczty
LFD działa — potwierdzone za pomocą systemctl status lfd

LF_PERMBLOCK_COUNT i LF_PERMBLOCK_INTERVAL są skonfigurowane do eskalacji recydywistów
CT_LIMIT jest ustawiony i dostrojony do oczekiwanej szczytowej liczby jednoczesnych połączeń
SYNFLOOD = "1" jest włączony z wartościami szybkości odpowiednimi dla Twojego wolumenu ruchu
Alerty e-mail są skonfigurowane i testowy alert został odebrany
cPHulk jest wyłączony w WHM, aby zapobiec konfliktom z LFD
Cotygodniowe zadanie cron csf -u jest zaplanowane
Dostęp przez konsolę/IPMI został przetestowany niezależnie od SSH
Reguły portów wychodzących (TCP_OUT) zostały zwalidowane — aktualizacje cPanel, Let’s Encrypt i NTP działają poprawnie
Jeśli używasz Cloudflare, zakresy adresów IP Cloudflare są na białej liście w csf.allow

FAQ

Jaka jest różnica między CSF a sprzętowym firewallem i czy potrzebuję obu?

Sprzętowy firewall działa na obrzeżu sieci i filtruje ruch przed dotarciem do karty sieciowej serwera. CSF działa na poziomie systemu operacyjnego i dodaje świadome aplikacyjnie, behawioralne wykrywanie, którego sprzętowe firewalle nie mogą zapewnić — takie jak blokowanie adresu IP po wielokrotnych nieudanych logowaniach do cPanel. W środowisku produkcyjnym obie warstwy są komplementarne. Filtrowanie sprzętowe redukuje wolumetryczne obciążenie DDoS; CSF obsługuje ukierunkowane próby włamania.

Jak odblokować adres IP, który CSF trwale zablokował?

Uruchom csf -dr BLOCKED.IP.ADDRESS, aby usunąć go z listy odmów, a następnie csf -r, aby przeładować reguły. Alternatywnie użyj interfejsu wtyczki CSF w WHM w sekcji „Odblokuj adres IP”. Aby zapobiec ponownemu blokowaniu, dodaj adres IP do csf.allow za pomocą csf -a IP.ADDRESS "reason".

Czy CSF będzie zakłócać odnawianie certyfikatów Let’s Encrypt / AutoSSL?

Tylko jeśli port 80 wychodzący jest zablokowany w TCP_OUT lub jeśli adresy IP serwera walidacji Let’s Encrypt są przypadkowo w csf.deny. Upewnij się, że port 80 jest zarówno w TCP_IN (dla odpowiedzi na wyzwania HTTP-01), jak i w TCP_OUT (dla komunikacji z serwerem ACME). Jeśli odnawianie kończy się niepowodzeniem po instalacji CSF, sprawdź csf.deny pod kątem zakresów adresów IP Let’s Encrypt i przejrzyj /var/log/lfd.log pod kątem zablokowanych połączeń wychodzących.

Jak bezpiecznie przetestować nową regułę CSF bez ryzyka blokady?

Tymczasowo ponownie włącz tryb testowy, ustawiając TESTING = "1" w csf.conf i uruchamiając csf -r. W trybie testowym reguły są ładowane, ale nie egzekwowane, a LFD nie uruchamia się. Zwaliduj swoje zmiany, a następnie ustaw TESTING = "0" i przeładuj. Zawsze miej potwierdzony dostęp do konsoli przed powrotem do trybu egzekwowania.

Czy CSF chroni przed atakami na warstwę aplikacji, takimi jak SQL injection lub XSS?

Nie. CSF działa na warstwach sieciowej i transportowej (L3/L4) i nie ma wglądu w ładunki żądań HTTP. Ataki na warstwę aplikacji wymagają Web Application Firewall (WAF), takiego jak ModSecurity z zestawem reguł OWASP Core Rule Set, który integruje się z Apache i Nginx na serwerach cPanel. CSF i ModSecurity są komplementarne — CSF obsługuje zagrożenia na poziomie sieci, podczas gdy ModSecurity obsługuje ataki na poziomie HTTP. LFD można skonfigurować do blokowania adresów IP, które wielokrotnie wyzwalają reguły ModSecurity, za pomocą dyrektywy LF_MODSEC.