397 lines
14 KiB
Text
397 lines
14 KiB
Text
<!--
|
|
The FreeBSD Polish Documentation Project
|
|
|
|
$FreeBSD$
|
|
Original revision: 1.25
|
|
-->
|
|
|
|
<!DOCTYPE article PUBLIC "-//FreeBSD//DTD DocBook V4.1-Based Extension//EN" [
|
|
<!ENTITY % man PUBLIC "-//FreeBSD//ENTITIES DocBook Manual Page Entities//EN">
|
|
%man;
|
|
]>
|
|
|
|
<article lang="pl">
|
|
<articleinfo>
|
|
<title>Firewall na połączeniu modemowym w FreeBSD</title>
|
|
|
|
<authorgroup>
|
|
<author>
|
|
<firstname>Marc</firstname>
|
|
<surname>Silver</surname>
|
|
<affiliation>
|
|
<address><email>marcs@draenor.org</email></address>
|
|
</affiliation>
|
|
</author>
|
|
</authorgroup>
|
|
|
|
<releaseinfo>$FreeBSD$</releaseinfo>
|
|
|
|
<abstract>
|
|
<para>W niniejszym artykule przedstawiono instrukcję konfiguracji
|
|
firewalla przy dynamicznie przydzielanym adresie IP, a także
|
|
przepis na uruchomienie takiego firewalla w FreeBSD, korzystając
|
|
z IPFW.
|
|
Artykuł nie zawiera instrukcji konfigurowania połączenia
|
|
PPP.</para>
|
|
</abstract>
|
|
</articleinfo>
|
|
|
|
<sect1 id="preface">
|
|
<title>Wstęp</title>
|
|
|
|
<para>Firewall na połączeniu modemowym w FreeBSD</para>
|
|
|
|
<para>Niniejszy artykuł opisuje konfigurację firewalla w FreeBSD
|
|
w przypadku, gdy adres IP przydzielany jest dynamicznie przez
|
|
dostawcę usług internetowych. Dołożono wszelkich starań, aby
|
|
artykuł zawierał przydatne informacje i był wolny od błędów,
|
|
jednakże wszelkie uwagi i sugestie są mile widziane, proszę
|
|
kierować je do <email>marcs@draenor.org</email>.</para>
|
|
</sect1>
|
|
|
|
<sect1 id="kernel">
|
|
<title>Opcję jądra</title>
|
|
|
|
<para>Na początek będziemy musieli przekompilować jądro. Wiecej
|
|
informacji na temat kompilowania jądra znaleźć można w <ulink
|
|
URL="../../books/handbook/kernelconfig.html">części Podręcznika
|
|
poświęconej konfiguracji jądra</ulink>. Do pliku konfiguracyjnego
|
|
jądra dopisujemy następujące opcje:</para>
|
|
|
|
<variablelist>
|
|
<varlistentry>
|
|
<term><literal>options IPFIREWALL</literal></term>
|
|
|
|
<listitem>
|
|
<para>Właczenie obsługi firewalla w jądrze.</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><literal>options IPFIREWALL_VERBOSE</literal></term>
|
|
|
|
<listitem>
|
|
<para>Wysyłanie informacji o pakietach do logów systemowych.</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><literal>options
|
|
IPFIREWALL_VERBOSE_LIMIT=<replaceable>100</replaceable></literal></term>
|
|
|
|
<listitem>
|
|
<para>Ograniczenie liczby pakietów zapisywanych w logach;
|
|
dzięki temu plik loga nie zostanie zapchany wieloma
|
|
powtarzającymi się wpisami. Wartość
|
|
<replaceable>100</replaceable> jest sensowna, można jednak
|
|
wstawić inną, odpowiednią dla własnych potrzeb.</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><literal>options IPDIVERT</literal></term>
|
|
|
|
<listitem>
|
|
<para>Włączenie gniazd divert.</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
</variablelist>
|
|
|
|
<para>Można dopisać jeszcze kilka wierszy
|
|
<emphasis>opcjonalnych</emphasis>, które zwiększają poziom
|
|
bezpieczeństwa. Firewall pracuje poprawnie również bez nich,
|
|
jednakże bardziej ostrożni użytkownicy mogą zechcieć z nich
|
|
skorzystać.</para>
|
|
|
|
<variablelist>
|
|
<varlistentry>
|
|
<term><literal>options TCP_DROP_SYNFIN</literal></term>
|
|
|
|
<listitem>
|
|
<para>Ignorowanie pakietów TCP z ustawionymi flagami
|
|
SYN i FIN. Zapobiega to możliwości identyfikacji stosu TCP/IP
|
|
przy pomocy narzędzi takich jak nmap, jest to jednak wbrew
|
|
ustaleniom dokumentu RFC1644. Nie powinno być stosowane,
|
|
jeśli na maszynie ma działać serwer WWW.</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
</variablelist>
|
|
|
|
<para>Po kompilacji jądra nie trzeba od razu przeładowywać systemu.
|
|
Jeśli wszystko pójdzie zgodnie z planem, wystarczy jedno
|
|
przeładowanie po ukończeniu konfiguracji firewalla.</para>
|
|
</sect1>
|
|
|
|
<sect1 id="rcconf">
|
|
<title>Uruchamianie firewalla w
|
|
<filename>/etc/rc.conf</filename></title>
|
|
|
|
<para>Trzeba teraz wprowadzić pewne zmiany w
|
|
<filename>/etc/rc.conf</filename>, by uwzględniał on firewalla.
|
|
Dodajemy następujące linijki:</para>
|
|
|
|
<programlisting>firewall_enable="YES"
|
|
firewall_script="/etc/firewall/fwrules"
|
|
natd_enable="YES"
|
|
natd_interface="tun0"
|
|
natd_flags="-dynamic"</programlisting>
|
|
|
|
<para>Informacje na temat działania powyższych poleceń można
|
|
znaleźć w <filename>/etc/defaults/rc.conf</filename> oraz
|
|
&man.rc.conf.5;.</para>
|
|
</sect1>
|
|
|
|
<sect1>
|
|
<title>Wyłączenie tłumaczenia adresów przez PPP</title>
|
|
|
|
<para>Jeżeli wykorzystywane jest tłumaczenie adresów
|
|
sieciowych
|
|
wbudowane w PPP, trzeba będzie je wyłączyć. W naszych przykładach
|
|
tłumaczeniem zajmuje się &man.natd.8;.</para>
|
|
|
|
<para>Fragment pliku odpowiedzialny za automatyczne uruchomienie
|
|
PPP wygląda zapewne tak:</para>
|
|
|
|
<programlisting>ppp_enable="YES"
|
|
ppp_mode="auto"
|
|
ppp_nat="YES"
|
|
ppp_profile="<replaceable>profile</replaceable>"</programlisting>
|
|
|
|
<para>Jeśli tak właśnie jest, trzeba będzie wyłączyć
|
|
<literal>ppp_nat</literal> wpisując
|
|
<literal>ppp_nat="NO"</literal> w
|
|
<filename>/etc/rc.conf</filename>. Ponadto należy usunąć
|
|
wpisy <literal>nat enable yes</literal> lub
|
|
<literal>alias enable yes</literal> w
|
|
<filename>/etc/ppp/ppp.conf</filename>.</para>
|
|
</sect1>
|
|
|
|
<sect1 id="rules">
|
|
<title>Reguły firewalla</title>
|
|
|
|
<para>Większość pracy mamy już za sobą. Pozostało już tylko
|
|
ustalenie reguł firewalla, po czym będzie można dokonać
|
|
przeładowania systemu i powinniśmy otrzymać działającego
|
|
firewalla. Zdaję sobie sprawę, że zbiór reguł zależy od
|
|
indywidualnych
|
|
potrzeb, starałem się jednak przygotować reguły odpowiednie
|
|
dla większości użytkowników łącz komutowanych. Można je
|
|
oczywiście dostosować samodzielnie, traktując poniższe reguły
|
|
jako punkt wyjścia. Zacznijmy od zamkniętego firewalla: z
|
|
założenia wszystkie pakiety są blokowane, przepuszczać
|
|
będziemy jedynie to, co jest nam rzeczywiście potrzebne.
|
|
Reguły powinny najpierw określać, co jest przepuszczane, potem
|
|
co jest blokowane. Podajemy więc wszystkie reguły
|
|
przepuszczające, a potem nakazujemy blokować całą resztę.
|
|
:)</para>
|
|
|
|
<para>Stwórzmy teraz katalog <filename
|
|
class="directory">/etc/firewall</filename>. W nim utwórzmy plik
|
|
<filename>fwrules</filename>, zgodnie z tym, co napisaliśmy
|
|
w <filename>rc.conf</filename>. Możemy oczywiście nazwać ten
|
|
plik jak nam się żywnie podoba, proponowana tu nazwa jest
|
|
jedną z możliwości.</para>
|
|
|
|
<para>Spójrzmy teraz na przykładowy plik firewalla, opatrzony
|
|
komentarzami.</para>
|
|
|
|
|
|
<programlisting>
|
|
# Reguły firewalla
|
|
# Autor: Marc Silver (marcs@draenor.org)
|
|
# http://draenor.org/ipfw
|
|
#
|
|
|
|
# Definicja komendy firewalla (jak w /etc/rc.firewall) upraszcza
|
|
# jej wywoływanie i czyni plik bardziej czytelnym.
|
|
fwcmd="/sbin/ipfw"
|
|
|
|
# Wyczyszczenie aktualnie obowiązujących reguł.
|
|
$fwcmd -f flush
|
|
|
|
# Przekierowanie wszystkich pakietów przez interfejs tun0.
|
|
$fwcmd add divert natd all from any to any via tun0
|
|
|
|
# Przepuszczanie danych przesyłanych przez kartę sieciową i lokalnie.
|
|
# Upewnij się, że wpisałeś tu właściwą kartę (w moim przypadku fxp0)
|
|
# zanim przeładujesz system. :)
|
|
$fwcmd add allow ip from any to any via lo0
|
|
$fwcmd add allow ip from any to any via fxp0
|
|
|
|
# Przepuszczanie wszystkich połączeń nawiązywanych przez nas.
|
|
$fwcmd add allow tcp from any to any out xmit tun0 setup
|
|
|
|
# Pozwalamy, by połączenia nawiązane mogły pozostać otwarte.
|
|
$fwcmd add allow tcp from any to any via tun0 established
|
|
|
|
# Zezwolenie na połączenia z zewnątrz z określonymi usługami na
|
|
# naszej maszynie. Przykładowo dopuszczamy połączenia z ssh i apache.
|
|
$fwcmd add allow tcp from any to any 80 setup
|
|
$fwcmd add allow tcp from any to any 22 setup
|
|
|
|
# Wysyłamy RESET w odpowiedzi na pakiety ident.
|
|
$fwcmd add reset log tcp from any to any 113 in recv tun0
|
|
|
|
# Pozwalamy na wychodzące zapytania DNS do wybranych serwerów.
|
|
$fwcmd add allow udp from any to <replaceable>x.x.x.x</replaceable> 53 out xmit tun0
|
|
|
|
# I oczywiście pozwalamy im odpowiedzieć... :)
|
|
$fwcmd add allow udp from <replaceable>x.x.x.x</replaceable> 53 to any in recv tun0
|
|
|
|
# Dopuszczenie pakietów ICMP (dzięki którym działają ping i traceroute).
|
|
# Można zdecydować się na ich blokowanie, ja jednak myślę, że mi się
|
|
# przydadzą.
|
|
$fwcmd add allow icmp from any to any
|
|
|
|
# Odrzucenie całej reszty.
|
|
$fwcmd add deny log ip from any to any
|
|
</programlisting>
|
|
|
|
<para>Zbudowaliśmy w pełni sprawny firewall zezwalający na połączenia
|
|
z portami 80 i 22, oraz rejestrujący próby połączenia z czymkolwiek
|
|
innym. Po przeładowaniu systemu powinien już należycie
|
|
funkcjonować. Jeżeli jakiekolwiek z podanych tu informacji
|
|
okażą się błędne, bądź będą powodować problemy, proszę o
|
|
zawiadomienie emailem. Mile widziane są również pomysły
|
|
na ulepszenie niniejszej strony.</para>
|
|
</sect1>
|
|
|
|
<sect1>
|
|
<title>Pytania</title>
|
|
|
|
<qandaset>
|
|
<qandaentry>
|
|
<question>
|
|
<para>Dlaczego korzystasz z &man.natd.8; i &man.ipfw.8;, a
|
|
nie z filtrów wbudowanych w &man.ppp.8;?</para>
|
|
</question>
|
|
|
|
<answer>
|
|
<para>Mówiąc szczerze, nie ma konkretnego powodu dla którego
|
|
zdecydowałem się na <command>ipfw</command> i
|
|
<command>natd</command>, a nie filtrowanie wbudowane w
|
|
<command>ppp</command>. Dyskusje przeprowadzone z
|
|
różnymi osobami doprowadziły do stwierdzenia, iż
|
|
<command>ipfw</command> jest z pewnością bardziej
|
|
rozbudowany i ma większe możliwości konfiguracji niż
|
|
filtry <command>ppp</command>, jest jednak trudniejszy
|
|
w używaniu. Jednym z powodów mojego wyboru jest
|
|
to, że wolę, by firewall działał na poziomie jądra systemu,
|
|
a nie programu użytkownika.</para>
|
|
</answer>
|
|
</qandaentry>
|
|
|
|
<qandaentry>
|
|
<question>
|
|
<para>Otrzymuję komunikat w rodzaju <errorname>limit 100
|
|
reached on entry 2800</errorname>, po którym w logach
|
|
nie pojawiają się informacje o zablokowanych pakietach.
|
|
Czy mój firewall nadal działa?</para>
|
|
</question>
|
|
|
|
<answer>
|
|
<para>Taki komunikat oznacza jedynie, że osiągnięty został
|
|
limit rejestrowania reguły. Sama reguła wciąż obowiązuje,
|
|
nie będzie już jednak rejestrowana, dopóki liczniki
|
|
rejestrowania nie zostaną wyzerowane; można to zrobić
|
|
poleceniem <command>ipfw resetlog</command>. Innym
|
|
rozwiązaniem jest zwiększenie limitu w konfiguracji
|
|
jądra przy pomocy opcji
|
|
<option>IPFIREWALL_VERBOSE_LIMIT</option>, tak jak
|
|
jest to opisane wcześniej. Limit można także ustawić
|
|
zmieniając wartość net.inet.ip.fw.verbose_limit
|
|
przy pomocy &man.sysctl.8;.</para>
|
|
</answer>
|
|
</qandaentry>
|
|
|
|
<qandaentry>
|
|
<question>
|
|
<para>W sieci wewnętrznej korzystam z adresów z puli prywatnej,
|
|
np. z zakresu 192.168.0.0, czy mogę uzupełnić reguły firewalla
|
|
wpisem w rodzaju
|
|
<literal>$fwcmd add deny all from any to
|
|
192.168.0.0:255.255.0.0 via tun0</literal> aby uniemożliwić
|
|
próby połączeń z zewnątrz z lokalnymi maszynami?</para>
|
|
</question>
|
|
|
|
<answer>
|
|
<para>Nie, ponieważ <emphasis>wszystko</emphasis> co
|
|
przechodzi przez <devicename>tun0</devicename> podlega
|
|
tłumaczeniu adresów realizowanemu przez
|
|
<command>natd</command>.
|
|
Pakiety przychodzące z zewnątrz trafiają wyłącznie do
|
|
dynamicznie przydzielonego adresu IP, a
|
|
<emphasis>nie</emphasis> do sieci wewnętrznej. Zauważmy
|
|
jednak, że można dodać regułę w rodzaju <literal>$fwcmd
|
|
add deny all from 192.168.0.4:255.255.0.0 to any
|
|
via tun0</literal>, która zabroni maszynie w sieci
|
|
wewnętrznej komunikowania się ze światem przez
|
|
firewall.</para>
|
|
</answer>
|
|
</qandaentry>
|
|
|
|
<qandaentry>
|
|
<question>
|
|
<para>Coś musi być nie tak. Postępowałem dokładnie według
|
|
wskazówek i jestem w kropce.</para>
|
|
</question>
|
|
|
|
<answer>
|
|
<para>W artykule przyjmujemy, że korzystamy z
|
|
<emphasis>userland-ppp</emphasis>, reguły obowiązują więc
|
|
dla interfejsu <devicename>tun0</devicename>, odpowiadającemu
|
|
pierwszemu połączeniu nawiązanemu przez &man.ppp.8;
|
|
(zwanemu także <emphasis>user-ppp</emphasis>). Dodatkowym
|
|
połączeniom odpowiadać będą interfejsy
|
|
<devicename>tun1</devicename>, <devicename>tun2</devicename>
|
|
itd. </para>
|
|
|
|
<para>W przypadku &man.pppd.8; jest
|
|
z kolei wykorzystywany
|
|
interfejs <devicename>ppp0</devicename>, jeśli
|
|
więc połączenie jest realizowane za pośrednictwem
|
|
&man.pppd.8;, w miejscu <devicename>tun0</devicename>
|
|
trzeba wstawić <devicename>ppp0</devicename>. Poniżej
|
|
przedstawiona jest szybka metoda uwzględnienia tej zmiany
|
|
w regułach firewalla. Oryginalny plik z regułami
|
|
zachowywany jest pod nazwą
|
|
<filename>fwrules_tun0</filename>.</para>
|
|
|
|
<screen> &prompt.user; <userinput>cd /etc/firewall</userinput>
|
|
/etc/firewall&prompt.user; <userinput>su</userinput>
|
|
<prompt>Password:</prompt>
|
|
/etc/firewall&prompt.root; <userinput>mv fwrules fwrules_tun0</userinput>
|
|
/etc/firewall&prompt.root; <userinput>cat fwrules_tun0 | sed s/tun0/ppp0/g > fwrules</userinput>
|
|
</screen>
|
|
|
|
<para>By przekonać się, czy w użyciu jest &man.ppp.8;, czy
|
|
&man.pppd.8;, można po nawiązaniu połączenia
|
|
posłużyć się &man.ifconfig.8;. W przypadku połączenia
|
|
nawiązanego przez &man.pppd.8; zobaczylibyśmy coś
|
|
w rodzaju (pomijając nieistotne informacje):</para>
|
|
|
|
<screen> &prompt.user; <userinput>ifconfig</userinput>
|
|
<emphasis>(nieistotne...)</emphasis>
|
|
ppp0: flags=<replaceable>8051<UP,POINTOPOINT,RUNNING,MULTICAST> mtu 1524</replaceable>
|
|
inet <replaceable>xxx.xxx.xxx.xxx</replaceable> -************-> <replaceable>xxx.xxx.xxx.xxx</replaceable> netmask <replaceable>0xff000000</replaceable>
|
|
<emphasis>(nieistotne...)</emphasis>
|
|
</screen>
|
|
|
|
<para>Natomiast gdy nawiązanie połączenia odbyło się za
|
|
pośrednictwem &man.ppp.8; (<emphasis>user-ppp</emphasis>),
|
|
ujrzymy coś takiego:</para>
|
|
|
|
<screen> &prompt.user; <userinput>ifconfig</userinput>
|
|
<emphasis>(nieistotne...)</emphasis>
|
|
ppp0: flags=<replaceable>8010<POINTOPOINT,MULTICAST> mtu 1500</replaceable>
|
|
<emphasis>(nieistotne...)</emphasis>
|
|
tun0: flags=<replaceable>8051<UP,POINTOPOINT,RUNNING,MULTICAST> mtu 1524</replaceable>
|
|
<emphasis>(nieistotne IPv6...)</emphasis>
|
|
inet <replaceable>xxx.xxx.xxx.xxx</replaceable> -************-> <replaceable>xxx.xxx.xxx.xxx</replaceable> netmask <replaceable>0xffffff00</replaceable>
|
|
Opened by PID <replaceable>xxxxx</replaceable>
|
|
<emphasis>(nieistotne...)</emphasis></screen>
|
|
</answer>
|
|
</qandaentry>
|
|
</qandaset>
|
|
</sect1>
|
|
</article>
|