Dziś przeglądałem się liście tematów do opisania, i gdzieś tam na dole, trochę zapomniane grzecznie czekały tematy związane z podstawową konfiguracją serwera opartego (nie tylko) o system Debian (dedykowany, Raspberry Pi czy VPS, nie ma znaczenia). Część zagadnień już za nami, ale zostało jeszcze kilka, może nie tak nośnych jak choćby instalacja i konfiguracja serwera WWW, ale moim zdaniem są to tematy niezbędne – związane z bezpieczeństwem. Dlatego w najbliższych dniach spodziewajcie się 4-6 wpisów poświęconych podstawowym środkom bezpieczeństwa (nie tylko) na serwerze, po których spróbuję zrobić wpis z małym podsumowanie, i zebraniem wszystkich najważniejszych tematów w jednym miejscu/wpisie. Dziś firewall – prosty, a skuteczny…
Spis treści w artykule
UFW – Uncomplicated Firewall
Programem, który wykorzystamy do stworzenia/skonfigurowania naszej zapory sieciowej (firewall) będzie UFW, który tak naprawdę jest pewnego rodzaju nakładką na IPtables, ale dzięki swojej skuteczności i prostocie obsługi ma wielu zwolenników.
Instalacja i podstawowa konfiguracja
Standardowo zaczniemy od instalacji, a ta będzie prosta – bo UFW znajduje się w repozytoriach Debiana (Raspbiana, Ubuntu), więc wystarczy skorzystać z polecenia:
sudo apt-get install ufw
Po instalacji jeszcze włączymy automatyczny start usługi wraz z systemem:
sudo nano /etc/ufw/ufw.conf
I zmieniamy:
ENABLED=no
na:
ENABLED=yes
Można się jeszcze upewnić, czy mamy aktywną obsługę IPv6:
IPV6=yes
Nawet jak teraz/jeszcze nie korzystacie z IPv6, to nie zaszkodzi – będzie na przyszłość.
Status usługi
Zanim zaczniemy jakiekolwiek zmiany w konfiguracji dotyczące blokowania, sprawdzamy status usługi, by później nie było niespodzianek:
sudo ufw status verbose
Raczej na pewno otrzymacie w odpowiedzi:
Status: inactive
Gdyby status był „active” (mało prawdopodobne na tym etapie, ale…), to przed dalszą konfiguracją warto tymczasowo wyłączyć UFW:
sudo ufw disable
oraz zrestartować do wartości domyślnych:
sudo ufw reset
Konfiguracja reguł
Standardowo zaczynam konfigurację reguł UFW od 2 podstawowych reguł:
sudo ufw default deny incoming
sudo ufw default allow outgoing
Pierwsza blokuje cały ruch przychodzący, druga pozwala na ruch wychodzący, co jest bazą dla pozostałych reguł, w których będziemy zezwalać na połączenia przychodzące dla różnych portów/usług.
Struktura poleceń
Zacznę od zaprezentowania podstawowych poleceń, i będą to chyba najczęściej używane/najpopularniejsze, choć nie obiecuje, że wszystkie:
sudo ufw allow [nazwa_usługi]
sudo ufw allow [port]
sudo ufw allow [port_od]:[port_do]
sudo ufw allow [port]/[typ_połączenia]
sudo ufw allow [port_od]:[port_do]/[typ_połączenia]
sudo ufw allow from [adres_IP]
sudo ufw allow from [adres_IP] to any port [port]
sudo ufw allow from [adres_IP]/[maska_sieciowa] to any port [port]
sudo ufw allow from [adres_IP]/[maska_sieciowa] to any port [port] proto [typ_połączenia]
sudo ufw allow in on [interfejs_sieciowy] to any port [port]
sudo ufw insert [numer_reguły] deny [port]
sudo ufw insert [numer_reguły] deny from [adres_IP]
Pewnie część z Was się domyśliła, że tam, gdzie jest „allow” (zezwól) można wpisać „deny” (zabroń), by stworzyć regułę blokującą, zamiast zezwalającej.
To wyjaśnię jeszcze pozostałe zwroty, choć pewnie część/większość również jest dość oczywista:
- [nazwa_usługi] – zamiast podawać konkretny port czy ty protokołu można podać nazwę usługi (np. ssh, http, https). Raczej nie korzystam, wolę ręcznie/samodzielnie wskazać co, gdzie i jak
- [port] – port, na którym nasłuchuje jakaś usługa, a których chcemy otworzyć (np. 80 dla HTTP, 443 dla HTTPS, 3306 dla MySQL)
- [port_od]:[port_do] – zakres portów, „od – do” (np. 80-88)
- [typ_połączenia] – możecie sprecyzować czy reguła dotyczy protokołu „tcp” czy „udp” (domyślnie oba)
- [adres_IP] – ograniczamy działanie reguły do konkretnego adresu IP (np. 123.123.123.123)
- [maska_sieciowa] – maska sieciowa, dzięki której możemy za pomocą jednej reguły zdefiniować wiele adresów IP, np. całą sieć LAN
- [interfejs_sieciowy] – oznaczenie karty sieciowej, dla ruchu, na której reguła będzie mieć zastosowanie (np. eth0)
- [numer_reguły] – reguły dotyczące blokowania warto dawać na górze, przed regułami zezwalającymi (w dalszej części będzie o wyświetlaniu zdefiniowanych reguł)
Tak jak napisałem powyżej – pewnie nie wyczerpałem wszystkich dostępnych poleceń dotyczących tworzenia reguł, ale na pewno te podstawowe. Zresztą jak chyba widać na przykładach – można poszczególne elementy właściwie dowolnie ze sobą mieszać/łączyć.
Przykładowe reguły
Poniżej kilka przykładowych reguł – niekoniecznie używanych przeze mnie, ale dotyczących dość popularnych usług, a zarazem pozwalających zobrazować to, o czym pisałem powyżej.
Serwer SSH na porcie 22 (choć zawsze zalecam zmianę):
sudo ufw allow 22
Serwer WWW na porcie 80:
sudo ufw allow 80
Serwer WWW, połączenie szyfrowane na porcie 443:
sudo ufw allow 443
Serwer miniDLNA na porcie 8200, dostępne tylko sieci LAN 10.0.*.*:
sudo ufw allow from 10.0.0.1/16 to any port 8200
Serwer CUPS na porcie 631:
sudo ufw allow from 10.0.0.1/16 to any port 631
Serwer Samba, dostęp z sieci LAN + oddzielne porty dla oddzielnych typów połączenia:
sudo ufw allow from 10.0.0.1/16 to any port 137 proto udp
sudo ufw allow from 10.0.0.1/16 to any port 138 proto udp
sudo ufw allow from 10.0.0.1/16 to any port 139 proto tcp
sudo ufw allow from 10.0.0.1/16 to any port 445 proto tcp
Serwer NTP na porcie 123:
sudo ufw allow 123/udp
Serwer VPN PPTP na porcie 1723:
sudo ufw allow 1723
W przypadku usługi VPN (PPTP) samo otwarcie portu może być za mało – w systemie Raspbian/Debian 7 Wheezy nie było takiej potrzeby, to już w Raspbian/Debian 8 Jessie bez tych dodatkowych operacji UFW nie pozwoli na korzystanie z VPNa.
Zaczynamy od edycji pliku:
sudo nano /etc/ufw/before.rules
gdzie dodajemy:
# Dla VPN/PPTP
-A ufw-before-input -p 47 -j ACCEPT
-A ufw-before-output -p 47 -j ACCEPT
Ja zazwyczaj dodaję zaraz po fragmencie:
# Don't delete these required lines, otherwise there will be errors * filter
(...)
# End required lines
Dodatkowo w pliku:
sudo nano /etc/default/ufw
zmieniamy:
DEFAULT_FORWARD_POLICY="DROP"
na:
DEFAULT_FORWARD_POLICY="ACCEPT"
Start usługi
Gdy już zablokowaliście wszystkie połączenia przychodzące, zezwoliliście na połączenia wychodzące, i odblokowaliście choćby port dla SSH (jeśli tak jesteście połączeni z serwerem/komputerem) możecie aktywować zaporę za pomocą polecenia:
sudo ufw enable
Jeśli jesteście pewni, że wszystko jest OK, na pytanie, które pojawi się przy próbie uruchomienia zapory, odpowiadacie „y”:
Command may disrupt existing ssh connections. Proceed with operation (y|n)? y
Firewall is active and enabled on system startup
Lista reguł, stan zapory
W każdej chwili – po aktywacji usługi – może sprawdzić listę ustawionych/zdefiniowanych reguł za pomocą polecenia:
sudo ufw status
lub:
sudo ufw status verbose
Przykładowa odpowiedź:
Status: active
Logging: on (low)
Default: deny (incoming), allow (outgoing)
New profiles: skip
To Action From
-- ------ ----
22 ALLOW IN Anywhere
1723 ALLOW IN Anywhere
80 ALLOW IN Anywhere
443 ALLOW IN Anywhere
8200 ALLOW IN 10.0.0.1/16
631 ALLOW IN 10.0.0.1/16
137/udp ALLOW IN 10.0.0.1/16
138/udp ALLOW IN 10.0.0.1/16
139/tcp ALLOW IN 10.0.0.1/16
445/tcp ALLOW IN 10.0.0.1/16
123/udp ALLOW IN Anywhere
22 ALLOW IN Anywhere (v6)
1723 ALLOW IN Anywhere (v6)
80 ALLOW IN Anywhere (v6)
443 ALLOW IN Anywhere (v6)
123/udp ALLOW IN Anywhere (v6)
Choć jak polecam wersję z numerowaniem, co przyda się np. przy kasowaniu niepotrzebnych reguł:
sudo ufw status numbered
W odpowiedzi – dla naszego testowego zestawu – zobaczycie coś takiego:
Status: active
To Action From
-- ------ ----
[ 1] 22 ALLOW IN Anywhere
[ 2] 1723 ALLOW IN Anywhere
[ 3] 80 ALLOW IN Anywhere
[ 4] 443 ALLOW IN Anywhere
[ 5] 8200 ALLOW IN 10.8.0.0/16
[ 6] 631 ALLOW IN 10.8.0.0/16
[ 7] 137/udp ALLOW IN 10.8.0.0/16
[ 8] 138/udp ALLOW IN 10.8.0.0/16
[ 9] 139/tcp ALLOW IN 10.8.0.0/16
[10] 445/tcp ALLOW IN 10.8.0.0/16
[11] 123/udp ALLOW IN Anywhere
[12] 22 ALLOW IN Anywhere (v6)
[13] 1723 ALLOW IN Anywhere (v6)
[14] 80 ALLOW IN Anywhere (v6)
[15] 443 ALLOW IN Anywhere (v6)
[16] 123/udp ALLOW IN Anywhere (v6)
Kasowanie niepotrzebnych reguł
Kasować reguły możecie za pomocą polecenia, za pomocą którego zostały wcześniej utworzone – wystarczy po „ufw” dodać „delete”:
sudo ufw delete allow 22
sudo ufw delete allow 123/udp
To moim zdaniem dużo wygodniejszą metodą jest skorzystanie z polecenia:
sudo ufw status numbered
Co spowoduje wyświetlenie listy reguł z przyporządkowanymi im numerami:
Status: active
To Action From
-- ------ ----
[ 1] 22 ALLOW IN Anywhere
[ 2] 1723 ALLOW IN Anywhere
[ 3] 80 ALLOW IN Anywhere
[ 4] 443 ALLOW IN Anywhere
[ 5] 8200 ALLOW IN 10.8.0.0/16
[ 6] 631 ALLOW IN 10.8.0.0/16
[ 7] 137/udp ALLOW IN 10.8.0.0/16
[ 8] 138/udp ALLOW IN 10.8.0.0/16
[ 9] 139/tcp ALLOW IN 10.8.0.0/16
[10] 445/tcp ALLOW IN 10.8.0.0/16
[11] 123/udp ALLOW IN Anywhere
[12] 22 ALLOW IN Anywhere (v6)
[13] 1723 ALLOW IN Anywhere (v6)
[14] 80 ALLOW IN Anywhere (v6)
[15] 443 ALLOW IN Anywhere (v6)
[16] 123/udp ALLOW IN Anywhere (v6)
Dzięki temu możemy kasować reguły szybko i precyzyjnie za pomocą polecenia:
sudo ufw delete 1
Co spowoduje skasowanie reguły:
[ 1] 22 ALLOW IN Anywhere
Reset ułatwień
Gdyby tak się stało, że z jakichś przyczyn (np. testy ;-)) tak namieszaliście w konfiguracji, że sami już nie wiecie która reguła, do czego służy, to zawsze możecie zresetować/wyczyścić dodane reguły:
sudo ufw reset
Tylko pamiętajcie, by wcześniej – na wszelki wypadek – zdezaktywować zaporę:
sudo ufw disable
GUFW, czyli UFW z graficznym interfejsem użytkownika (GUI)
Jeśli zamiast poleceń wydawanych z konsoli (wiersza poleceń – windowsowiec ze mnie) wolicie korzystać z graficznego interfejsu użytkownika, to możecie doinstalować sobie program GUFW:
sudo apt-get install gufw
Program ten uruchomicie bezpośrednio z poziomu systemu (gdy korzystacie z trybu graficznego), lub gry u Was tak jak u mnie Linux to tylko konsola (tylko na potrzeby serwerów, prywatnie/na co dzień Windows ;-)) za pomocą X11/Xming:
gksudo gufw
W głównym oknie programu znajdziecie status usługi, podstawowe opcje związane ze sterowaniem UFW, oraz listę zdefiniowanych reguł:
Samo dodawanie reguł oczywiście też możecie wykonać w trybie graficznym, tutak w trybie zaawansowanym:
Podsumowanie
I to właściwie wszystko – mam nadzieję, że dzięki temu poradnikowi Ci z Was (zwłaszcza na serwerze), którzy do tej pory nie korzystali z żadnej zapory, zdecydują się na wdrożenie u siebie choćby UFW, co jest, jak widzieliście – a przynajmniej mam taką nadzieje – proste, a zarazem skuteczne.
By uzyskać więcej informacji, wystarczy, że skorzystacie z polecenia:
man ufw
Jak napisałem we wstępie – to pierwszy wpis z kilku które wisiały, a które chyba pozwolą nam zamknąć temat przygotowania serwera VPS do pracy jako m.in. serwer WWW…
- Wakacje składkowe ZUS a zawieszenie działalności gospodarczej, czyli uważaj, bo być może nie będziesz mógł skorzystać (w 2024) - 1970-01-01
- Przykładowy kalkulator wyceny usługi druku 3D, czyli nie tylko materiał się liczy - 1970-01-01
- Home Assistant 2024.10, czyli nowa karta „nagłówek” i niedziałający TTS w ramach usługi Google Cloud - 1970-01-01
— ——— –
[ 1] 22 ALLOW IN Anywhere
[ 2] 80 ALLOW IN Anywhere
[ 3] 443 ALLOW IN Anywhere
[ 4] 8200 ALLOW IN 10.0.0.0/16
[ 5] 631 ALLOW IN 10.0.0.0/16
[ 6] 137/udp ALLOW IN 10.0.0.0/16
[ 7] 138/udp ALLOW IN 10.0.0.0/16
[ 8] 139/tcp ALLOW IN 10.0.0.0/16
[ 9] 445/tcp ALLOW IN 10.0.0.0/16
[10] 123/udp ALLOW IN Anywhere
[11] 1723 ALLOW IN Anywhere
[12] 50748/udp ALLOW IN Anywhere
[13] 68/udp ALLOW IN Anywhere
[14] 5353/udp ALLOW IN Anywhere
[15] 10068/tcp ALLOW IN Anywhere
[16] 20068/tcp ALLOW IN Anywhere
[17] 37698/udp ALLOW IN Anywhere
[18] 46046/udp ALLOW IN Anywhere
[19] 52306/udp ALLOW IN Anywhere
[20] 22 (v6) ALLOW IN Anywhere (v6)
[21] 80 (v6) ALLOW IN Anywhere (v6)
[22] 443 (v6) ALLOW IN Anywhere (v6)
[23] 123/udp (v6) ALLOW IN Anywhere (v6)
[24] 1723 (v6) ALLOW IN Anywhere (v6)
[25] 50748/udp (v6) ALLOW IN Anywhere (v6)
[26] 68/udp (v6) ALLOW IN Anywhere (v6)
[27] 5353/udp (v6) ALLOW IN Anywhere (v6)
[28] 10068/tcp (v6) ALLOW IN Anywhere (v6)
[29] 20068/tcp (v6) ALLOW IN Anywhere (v6)
[30] 37698/udp (v6) ALLOW IN Anywhere (v6)
[31] 46046/udp (v6) ALLOW IN Anywhere (v6)
[32] 52306/udp (v6) ALLOW IN Anywhere (v6)
czy tak jest dobrze? pewne opcje same sie otworzyly, glownie v6
Czy jest dobrze czy nie, to zależy od tego jakie usługi mają działać na serwerze, i skąd i kto ma mieć do nich dostęp. Ważne, by nie odciąć sobie dostępu do serwera po SSH (choć zazwyczaj wtedy można ratować się konsolą lokalną, w panelu zarządzania serwerem lub mając fizyczny dostęp do komputera), ale tu widzę, że dostęp na porcie 22 jest otwarty, więc jakby coś poszło nie tak, to zawsze będzie można skorygować ustawienia (choć zalecam zmienić adres na którym działa usługa SSH i/lub zainstalować i skonfigurować dodatkowo np. Fail2Ban).
Reguły dla IPv6 w standardowej konfiguracji tworzą się automatycznie, więc jest to normalne, i może się przydać w przypadku przejścia na IPv6…
Nie sprecyzowales ,,sudo ufw allow [port_od]:[port_do]” skad mam to do cholery wiedziec? Mam port 22…eh potrzebuje pomocy z tymi zaporami nie mam nikogo kto by mogl mi pomoc.
We wpisie jest „sprecyzowane” wszystko co trzeba, a nawet więcej. Jak dalej jest to niejasne, to odsyłam do pomocy UFW, ew. warto się zastanowić, czy zarządzanie VPSem to jest to, co na pewno powinieneś robić samodzielnie.
Polecenie na które zwróć uwagę to:
A konkretnie, dla portu 22 będzie to:
Zresztą masz to w przykładowych regułach:
Wystarczy przeczytać, pomyśleć i zastosować... ;-)
Witam serdecznie, czy odblokowanie tych trzech portów w systemie Linux wystarczy dla starszej osoby to ma być system, do przeglądania internetu. Użyłem takich poleceń. Czy może pan napisać czy to jest bezpieczne rozwiązanie, przeglądarka dobrze działa, aktualizacje system pobiera.
sudo ufw default deny incoming
sudo ufw default allow outgoing
sudo ufw allow 22
sudo ufw allow 80
sudo ufw allow 443
sudo ufw enable
sudo ufw status verbose
Jeśli ma to być zwykła stacja robocza, taka np. do internetu (dodatkowo pewnie też do internetu łącząca się przez router), to zabawa w UFW raczej jest zbyteczna. Poradnik dotyczy maszyn/komputerów dostępnych bezpośrednio z internetu, np. serwerów. Stąd np. informacja o porcie 22, który domyślnie służy do łączenia się po SSH, i w warunkach domowych niekoniecznie w ogóle będzie używany (a nawet jeśli, to zakładam, że w ramach sieci LAN).
Niby tak, ale czy menadżer pakietów który aktualizuje system i instaluje pakiety nie wymaga czasem SSH?
Jeśli jest obsługiwany lokalnie, z komputera, to po co mu SSH? Jako przykład podam Raspberry Pi i Raspbiana, opartego na Debianie: kiedyś SSH było domyślnie aktywne, a od dość dawna – chyba m.in. ze względów bezpieczeństwa – domyślnie jest wyłączone (można szybko i łatwo aktywować przez raspi-config, ale wymaga to aktywności lokalnej, na komputerze).
Może masz na myśli nie tyle SSH (bezpieczne połączenie zdalne), co konsolę, coś jak wiersz poleceń (CMD) w Windowsie? Jeśli tak, to lokalnie konsola jest dostępna niezależnie od tego czy jest aktywne SSH, czy nie. Do tego, jeśli będą tam jakieś okienka (GUI), to obecnie raczej każda dystrybucja ma wbudowany w standardzie jakiś graficzny menedżer pakietów czy aktualizacji.
Chyba, że chcesz zdalnie (z innego urządzenia) zarządzać komputerem, to wtedy faktycznie – SSH się przyda.
Dzięki za wyjaśnienie, łączę się w laptopie przez WiFi, to mam tylko odblokowane te dwa porty 443 i 80. Coś tam sobie programuję na LAMP w przeglądarce i wszystko działa. Możliwe, że do MySQL będę musiał otworzyć port 3306.
Pozdrawiam serdecznie!
Te porty otwierasz tylko, gdy z innego komputera będziesz chciał się łączyć z usługami na tym komputerze (np. WWW w lokalnej sieci LAN). Jeśli „localhost”, to nie ma takiej potrzeby.
A jak używam programu filezilla to muszę odblokować port 21, aby wysłać plik na serwer?
Musisz rozdzielić reguły wychodzące, od przychodzących. Jeśli Ty łączysz się „w świat”, to wystarczy, że masz odblokowane połączenia wychodzące. W standardzie realizuje to komenda:
Porty na swoim komputerze (serwerze) odblokowujesz gdy do tego komputera (na danym porcie) będziesz chciał się łączyć, co w większości przypadków dotyczy serwerów różnych usług.
pytanie, załóżmy, że chciałbym bardziej brutalnie zamknąć FW stosując blokadę wyjścia:
sudo ufw default deny outgoing
i pootwierać tylko konkretne porty? czyli dać userowi dostęp do wybranych przeze mnie usług np 443 a już 80 nie… itp
nie wiem dlaczego dodanie np
ufw allow out 443/tcp nie załatwia sprawy?
dobra nie było pytania :) zapomniałem o porcie 53, a leciałem po nazwach :) dzięki :D
Narzędzie systemowe „syslog”, podaje taką informację :
„nf_conntrack: default automatic helper assignment has been turned off for security reasons and CT-based firewall rule not found.
Use the iptables CT target to attach helpers instead.”
dzieje się tak, po zainstalowaniu „ufw” programu wspomagającego, iptables.
Wyłączenie „ufw” powoduje niepojawianie się ww. komunikatu.
Czym to jest spowodowane?
Jak sobie poradzić bez odinstalowywania „ufw” ? Zważywszy, że bardzo ułatwia obsługę iptables.
Nie tylko nie podałeś swojego imienia, ale i nie napisałeś jakiej dystrybucji używasz. Po błędzie przypuszczam, że może to być bardziej wyluzowany brat Debiana, czyli Ubuntu. Niestety ja korzystam z Debiana, i choć w większości przypadków wszystko w tych dwóch dystrybucjach jest podobne, to jak widać nie wszędzie. Z tego, co kojarzę (potwierdź sobie jeszcze w wyszukiwarce) to w pliku konfiguracyjnym (/etc/default/ufw?) wywal moduły z parametru „IPT_MODULES”, czyli niech wygląda to tak:
Czy pomoże? Nie wiem, nie korzystam z Ubuntu (choć niebawem to się zmieni, bo jeden serwer będę musiał mieć właśnie na Ubuntu), ale takie coś znalazłem kiedyś i trafiło do moich notatek.
Jak wyłączyć całkowicie port? Dodałem takie reguły(dany_port to tylko przykład):
ufw deny dany_port
ufw deny dany_port/tcp
ufw deny dany_port/udp
sudo ufw status verbose
Status: active
Logging: on (low)
Default: deny (incoming), allow (outgoing), disabled (routed)
New profiles: skip
To Action From
— —— —-
dany_port DENY IN Anywhere
dany_port/tcp DENY IN Anywhere
dany_port/udp DENY IN Anywhere
dany_port (v6) DENY IN Anywhere (v6)
dany_port/tcp (v6) DENY IN Anywhere (v6)
dany_port/udp (v6) DENY IN Anywhere (v6)
Jednak polecenie
netstat -tapen
Pokazuje mi nadal połączenie na tym porcie, więc wychodzi na to, że go tylko zablokowałem, ale nie wyłączyłem?
Porty otwierają aplikacje/usługi, więc wyłączając je zamykasz port. Blokowanie jest nadrzędne, że nawet jak jakaś aplikacja otworzy, to i tak nie będzie na nim ruchu…
Witam,
Ja mam trochę inny problem z UFW. Generalnie wszystko działa, z tym, że po restarcie debiana UFW się wyłącza, przez co VPN mi nie działa.
Tak, wklepałem komendę sudo ufw enable, mimo to po restarcie mam status inactive.
Serwer www ogarnia mi myVesta
Jakieś sugestie? :-)
Nie znam myVesta, ale jeśli dobrze kojarzę, to jest to na Debianie i jest forkiem VestaCP. I jeśli (dalej) dobrze kojarzę, to – pzynajmniej w VestaCP – są tam jakieś różnice w obsłudze iptables, stąd nie wiem, czy korzystanie w tym systemie z UFW ma sens, i czy nie będzie powodować błędów.
Dobrze kojarzysz :-)
Tylko teraz główkuję jak dodać reguły do iptables, które mam w UFW. Niestety iptables jest trochę bardziej skomplikowany :/
Do tego w panelu myVesta w zakładce FIREWALL nie ma opcji które są mi potrzebne, więc zostaje dłubanie w konsoli.
W ufw miałem dodane:
sudo ufw allow proto gre from
-A ufw-before-input -p 47 -j ACCEPT
Teraz jak to dodać do iptables? ;)
WP wycięło mi „IP routera” z pierwszej komendy :-) Miało być
sudo ufw allow proto gre from IP routera
Z racji tego, ze UFW to taka pewnego rodzaju nakładka na iptables, to jest spora szansa, że jak dodasz regułę w UFW, to będziesz mógł ją podejrzeć w iptables za pomocą polecenia: sudo iptables -L
Znalazłem coś takiego:
ACCEPT gre — IP router anywhere
Tą drugą linijkę dodałem przez edycje pliku /etc/ufw/before.rules. Przydał by się odpowiednik w iptables :-)
Dzięki za dobre chęci :-)
Niestety, ale iptables to nie mój konik, więc nawet nie próbuję „przetłumaczyć” tego z UFW na iptables.