mogl bym tez dostac takiego gotowca?
pozdrawiam
lasic
----- Original Message -----
From: "Rafal Bierc" =
<rafaelb@interia.pl>
To: "demeus" <demeus@go2.pl>; =
<slacklist@slackware.com.pl>
Sent: Monday, March 24, 2003 8:45 PM
Subject: [slacklist] Re: Firewall
>
> Thx za opisik, jak jeszcze mozesz to podrzuc =
jakis przykladzik.:)
> I jezeli to nie zaduzo to czym mozna sprawdzic =
zrobionego firewall`a
chodzi mi o jego skutecznosc np. jaka strona co =
testuje , program lub
ploecenie
>
> Thx
> Rafal
> ----- Original Message -----
> From: demeus
> To: rafaelb@interia.pl
> Sent: Monday, March 24, 2003 6:09 =
PM
> Subject: Re: [slacklist] =
Firewall
>
>
> Ten artykuł powinien pozwolić =
Tobie na napisanie firewalla samemu...
>
> jesli beda jakies pytania to daj =
znac...
>
>
>
> Pakiet netfilter - obsługa =
filtrowania pakietów w Linuksie przez jądro w
wersji 2.4 (komenda iptables)
>
> Jeśli będziesz miał jakieś =
uwagi i komentarze to nie krępuj się i
napisz: gallegher@w.pl
>
> Polskie tłumaczenie howto do =
przeczytać najpierw, zanim zaczniesz czytać =
Przeczytaj również pozostałe tłumaczenia =
pojawiające się na stronie Łukasza
Bromirskiego - naprawdę warto. Zajrzyj również =
na stronę domową pakietu
netfilter.
>
> Taaaak. Widziałem, że nie =
będzie ci się chciało czytać takiej ilości
tekstu. Dobrze omówię bardzo oględnie jak =
wędrują pakiety w jądrze 2.4 - nie
będę omawiał składni komendy iptables. Jesli =
zajrzyj do howto, lub na stronę manuala =
>
> Podstawowym pojęciem jest =
łańcuch (chain). Łańcuch jest to zbiór reguł
filtrujących. Istnieją trzy standardowe =
łańcuchy: input, forward i output;
łańcuchy dodatkowe prerouting i forward; ponadto =
użytkownik może tworzyć
własne łańcuchy. Łańcuch jest listą =
reguł do których po kolei jest
porównywany pakiet. Jeśli pakiet pasuje do =
którejś z reguł, wykonywana jest
akcja zdefiniowana wewnatrz tej reguły. Reguły =
iptables. Jeśli pakiet nie pasuje do żadnej =
reguły wykonywana jest akcja
zdefiniowana w polityce danego łańcucha. Tylko =
łańcuchy podstawowe i
dodatkowe mają własną politykę, łańcuchy =
utworzone przez użytkownika nie
mają własnej polityki, a pakiet po przejściu =
przez taki łańcuch wraca do
łańcucha z którego został wywołany.
>
> =
&=
nbsp; ______
> =
&=
nbsp; / \
> >---[ PREROUTING ]---( ruting =
)---[ FORWARD ]--+--[POSTROUTING ]->
> =
&=
nbsp; =
\______/ =
; |
> =
&=
nbsp; =
| =
|
> =
&=
nbsp; =
V =
|
> =
&=
nbsp; [ INPUT =
] =
[ OUTPUT ]
> =
&=
nbsp; =
| =
^
> =
&=
nbsp; =
| =
|
> =
&=
nbsp; +--> procesy lokalne -+
>
> Pakiet sprawdzany jest najpierw w =
łańcuchu PREROUTING. Następnie
podjemowana jest decyzja czy pakiet skierowany jest =
wtedy przechodzi przez łańcuch INPUT i dociera do =
procesów lokalnych, czy
też do jednej z sieci, do których dany komputer =
jest ruterem. W takim
wypadku podejmowana jest decyzja o rutingu danego =
pakietu (w uproszczeniu -
definiowana karta sieciowa przez którą należy =
pakiet trafia do łańcucha FORWARD. Pakiety =
wygenerowane przez procesy
lokalne (np. przeglądarkę www wysylającą =
zapytanie o stronę) przechodzą
przez łańcuch OUTPUT. Następnie wszystkie =
pakiety przechodzą przez łańcuch
POSTROUTING i są wysyłane na karty =
sieciowe.
>
> Tak naprawdę to podstawowe =
łąńcuchy należą do tabeli filter. Jest to
główna tabela służąca do definiowania =
reguł filtrowania pakietów. Dodatkowo
istnieje tabela nat, w której definiujemy =
popularną "maskaradę" oraz tabela
mangle służąca do zmieniania zawartości =
pakietów przechodzących przez nasz
firewall. Nie wszystkie łańcuchy istnieją w =
poszczególnych tabelach.
>
> Do tabeli "mangle" =
(komenda: iptables -t mangle ...) należą łańcuchy:
> =
PREROUTING
> =
OUTPUT
>
> Do tabeli "nat" (komenda: =
> =
PREROUTING - DNAT (destination nat) podmieniany jest adres
docelowy pakietów
> =
POSTROUTING - SNAT (source nat) podmieniany jest adres =
źródłowy
pakietów
> =
OUTPUT - DNAT dla pakietów generowanych przez procesy lokalne
>
> Defaultową tabelą jest =
"filter" (komenda: iptables ... - nie trzeba
używać przełącznika -t), należą do niej =
łańcuchy:
> =
INPUT
> =
OUTPUT
> =
FORWARD
>
> Kolejność przechodzenia =
pakietów przez tabele: mangle -> nat -> filter.
>
>
> =
-------------------------------------------------------------------------=
-
----
>
>
>
>
>
> Tworzenie firewalla - =
wstęp.
>
> Postanowiłem omówić tworzenie =
firewalla, na konkretnym, praktycznym
przykładzie. Zakładam, że masz komputer =
podpięty do jakiegoś rodzaju łącza
stałego. Oczywiście potrzebujesz firewalla. =
Zawsze najlepszym wyjsciem, jest
gdy firewall jest dedykowanym serwerem na którym =
nie ma uruchomionych
żadnych dodatkowych usług. Dzięki temu nie ma =
możliwości (przynajmniej
teoretycznie) włamu do niego. Brzmi to bardzo =
poważnie, ale tak naprawdę nie
będzie zbyt dużo kosztowało. Wystarczy stare =
486DX i jakieś 16MB RAM-u,
czasem mozna dostać cos takiego za piwo od kogoś =
kto się chce pozbyć. Jeśli
nie masz dysku twardego, to możesz poszukać =
jakiejs jednodyskietkowej
dystrybucji Linuxa lub BSD przystosowanej do =
pełnienia roli rutera i
firewalla. Jednak wtedy najpewniej nie będziesz =
mógł skorzystac z
konfiguracji opisanej poniżej - wersje =
jednodyskietkowe Linuksów są
wykonywane najczęściej na jadrach serii 2.2, =
komendy ipchains. Jeśli chodzi o dystrybucję, to =
polecam S!
> lackware - spójrz na porównanie statystyk =
"dziur" dla tego systemu i np.
dla RedHata. Nie będę tutaj opisywał sposobu =
ten temat zbyt wiele wyspecjalizowanych stron. =
Główną zasadą jest
instalowanie jedynie niezbędnych pakietów. W ten =
sposób zmniejszasz
prawdopodobieństwo, że w przyszłości w jednym =
z zainstalowanych przez ciebie
pakietów zostanie odkryta jakaś dziura - im mniej =
pakietów zainstalowanych
tym mniejsze prawdopodobieństwo wykrycia =
>
> OK. Przejdźmy do sedna. Jednym z =
problemów może być umowa, którą
podpisałeś ze swoim dostawcą usług (ISP). =
Najczęściej jest w niej paragraf
mówiący, że możesz uruchomić tylko jeden =
terminal z dostępem do Internetu.
Uważam jednak, że jeśli uruchomisz jeden =
którego nie będziesz korzystał jak z terminala =
nie łamiesz ducha umowy (byćmoże łamiesz =
literę - nie jestem prawnikiem). W
opisanej przeze mnie konfiguracji opiszę jak =
utrudnić Adminom ISP wykrycie
działajacej u ciebie maskarady (a dokładniej =
NATu) i firewalla. Oczywiście
opiszę konfigurację dla udostepniania łącza =
uruchomić udostepnianie dla wiekszej ilości =
maszyn bedziesz musiał sam
trochę pomyśleć. Jeśli uda ci się =
przerobić podaną przeze mnie konfigurację,
to znaczy że i tak dałbyś radę to zrobić =
sam, w tym wypadku nie będę się
czuł winny złamania przez ciebie umowy. Poza tym =
wyraźnie piszę: każdy
uruchamia podane przeze mnie !
> skrypty na własną =
odpowiedzialność..
>
> Mam nadzieję, że =
przeczytałeś poprzednie rozdziały mojej strony -
sieci.krysiak.info, ponieważ aby zrozumieć =
będziesz potrzebował tej wiedzy.
>
>
> =
-------------------------------------------------------------------------=
-
----
>
> Tworzenie firewalla - =
podstawy.
>
> Ruter (i firewall), który =
konfigurujemy ma dwie karty sieciowe jedną -
eth0 - na zewnątrz z numerem IP przydzielonym przez =
naszego dostawcę usług i
drugą - eth1 - do naszej sieci lokalnej, której =
IP sami sobie konfigurujemy.
Jesli masz łacze SDI to najprawdopodobniej musisz =
wymienić wpisy eth0 na
ppp0.
>
> eth0
> przydzielony numer IP: =
111.222.333.444
> z maską 24 bity czyli =
255.255.255.0
> gateway (ruter): =
111.222.333.1
>
> eth1
> przyjmujemy numer IP: =
192.168.1.1
> z maską 30 bitów =
255.255.255.252
>
> komputer w sieci wewnętrznej =
konfigurujemy:
> numer IP: 192.168.1.2
> z maską 255.255.255.252
> gateway (ruter): 192.168.1.1
> serwery DNS ustawiamy na zalecane =
przez dostawcę usług.
>
> W przypadku Slackware'a =
wyremowałem (postawiłem na początku linii #) ze
skryptu /etc/rc.d/rc.inet1 wszystko poza =
linią:
>
> # poczatek skryptu =
/etc/rc.d/rc.inet1
> HOSTNAME=`cat =
/etc/HOSTNAME`
>
> Następnie konfigurujemy =
standardowe urządzenie lo.
>
> /sbin/ifconfig lo 127.0.0.1
> /sbin/route add -net 127.0.0.0 =
netmask 255.0.0.0 lo
>
> W moim przypadku włączamy =
potrzebne moduły do kart sieciowych 3Com:
>
> /sbin/modprobe 3c509
>
> A nastepnie przechodzimy do =
konfiguracji tychże kart sieciowych i
rutingu.
>
> /sbin/ifconfig eth0 111.222.333.444 =
netmask 255.255.255.0 broadcast
111.222.333.255 up
> /sbin/route add default gw =
111.222.333.1
> /sbin/ifconfig eth1 192.168.1.1 =
netmask 255.255.255.252 broadcast
192.168.1.3 up
>
> Dalej musimy włączyć NAT =
(czyli taką "lepszą maskaradę")
>
> modprobe ip_conntrack_irc
> modprobe ip_nat_irc
> iptables -t nat -A POSTROUTING -o =
SNAT --to-source=111.222.333.444
> echo "1" > =
/proc/sys/net/ipv4/ip_forward
> /etc/rc.d/firewall.start
> /usr/local/sbin/sshd
> # koniec skryptu =
/etc/rc.d/rc.inet1
>
> Komendami modprobe właczamy =
moduły do irca (jeśli będą nam potrzebne).
Komenda iptables uruchamia nam SNAT pakietów, =
który podmienia adres źródłowy
pakietów z naszej sieci wewnetrznej na adres =
111.222.333.444. W tym momencie
pakiety z naszego komputera o adresie 192.168.1.2 =
wychodząc w Internet (z
karty eth0) wydają się pochodzić z adresu =
111.222.333.444. Aby to zadziałało
musimy jeszcze uruchomić proces rutingu - dzieje =
się to w następnej linii.
Nastepnie uruchamiamy nasz skrypt firewall.start. Na =
koniec uruchamiamy
demona ssh (najlepiej w wersji 2) abyśmy mogli =
administrować naszym ruterem
z zewnątrz. W tym momencie zaczynamy pisanie =
skryptu firewalla
/etc/rc.d/firewall.start .
>
>
> =
-------------------------------------------------------------------------=
-
----
>
> Tworzenie firewalla - =
konfiguracja.
>
> Podstawową zasadą przy pisaniu =
reguł firewalla jest: najpierw stawiamy
barierę nie do przebycia dla żadnych pakietów, =
a następnie wybijamy w niej
przejścia tylko dla takiego ruchu, który chcemy =
przepuścić.
>
> W skrócie: co nie jest dozwolone - =
jest zabronione. Czyli po pierwsze
wybieramy połączenia które będą możliwe =
tym tak naprawdę powinniśmy również =
ściśle zdefiniować połączenia które host
z sieci wewnętrznej może dykonywać do Internetu =
oraz połączenia które
komputer (komputery) z sieci lokalnej mogą =
wykonywać do rutera. W przypadku
większej sieci tak właśnie się postępuje, =
jednak dla naszej sieci
składającej się jedynie z komputerów =
zarządzanych osobiście przez 1 osobę,
nie ma takiej potrzeby. Poza tym ograniczalibyśmy w =
ten sposób sobie samym
dostęp do różnych usług. Jest oczywiście =
niebezpieczeństwo takiego
postępowania, przykładowo w przypadku gdy na =
naszym komputerze pojawi się
się jakiś trojan, przy silnie restrykcyjnym =
firewallu, gdy trojan próbowałby
nawiązać połączenie na zewnątrz, =
zostałoby ono usunięte i mielibyśmy o tym
informację w logach systemowych. Oznacza to, że =
na komputerze lokalnym nie
możemy zaniedbać podstawowych zasa!
> d bezpieczeństwa i musimy zainstalować =
jakieś (często upgradowane)
oprogramowanie antywirusowe.
>
> Czyli zaczynamy. W katalogu =
/etc/rc.d/ tworzymy sobie skrypt
firewall.start, który jest uruchamiany z pliku =
rc.local (jest to poprawne
dla większości dystrybucji Linuksa). Moja =
konfiguracja została oparta na
opisie ze strony: =
www.sns.ias.edu/~jns/security/iptables - oczywiście
dokonałem w niej pewnych zmian. Nie będę =
tworzył skryptu
sparametryzowanego - jest on zbyt mało przejrzysty =
skryptami shellowymi, a ponadto gdy zaglądamy do =
niego po kilku miesiącach
jest trudniejszy w analizie. Przed komendami iptables =
występującymi w
skrypcie powinieneś dopisać pełną =
bezwzględną ścieżkę dostępu, np.:
/usr/local/sbin/iptables ...
>
> #!/bin/sh
> #Poczatek skryptu =
/etc/rc.d/firewall.start
>
> modprobe ip_tables
> modprobe ip_conntrack
> modprobe ip_conntrack_ftp
>
> iptables -P INPUT DROP
> iptables -P OUTPUT DROP
> iptables -P FORWARD DROP
>
> Najpierw próbujemy ładować =
moduły które mogą się nam przydać. Bardzo
ważnym modułem jest conntrack umożliwiający =
śledzenie połączeń. Dzięki niemu
możemy stwierdzić które pakiety nie są =
poprawnymi pakietami danego
połączenia. Moduł conntack potrafi śledzić =
- poza oczywistym protokołem TCP,
który jest protokołem połączeniowym) =
również protokoły UDP i ICMP. Lista
aktualnie śledzonych polączeń znajduje się w =
pliku /proc/net/ip_conntrack. W
ostatnich 3 liniach ustawiliśmy politykę =
podstawowych łańcuchów na DROP - w
tym momencie nasz host nie odbiera i nie przepuszcza =
żadnych pakietów. Teraz
wykonamy wstepną konfigurację parametrów =
jądra wpływających na działanie
stosu TCP/IP.
>
> # wylaczamy odpowiedzi na =
pingi
> /bin/echo "1" > =
/proc/sys/net/ipv4/icmp_echo_ignore_all
> # ochrona przed atakiem typu =
Smurf
> /bin/echo "1" > =
/proc/sys/net/ipv4/icmp_echo_ignore_broadcasts
> # Nie aktceptujemy pakietow =
"source route"
> /bin/echo "0" > =
/proc/sys/net/ipv4/conf/all/accept_source_route
> # Nie przyjmujemy pakietow ICMP =
rediect, ktore moga zmienic nasza
tablice rutingu
> /bin/echo "0" > =
/proc/sys/net/ipv4/conf/all/accept_redirects
> # Wlaczamy ochrone przed blednymi =
komunikatami ICMP error
> /bin/echo "1" > =
/proc/sys/net/ipv4/icmp_ignore_bogus_error_responses
> # wszystkie karty nie beda =
przyjmowaly pakietow z sieci innych niz te z
tablicy rutingu
> echo "1" > =
/proc/sys/net/ipv4/conf/all/rp_filter;
> # Wlacza logowanie dziwnych =
(spoofed, source routed, redirects) pakietow
> /bin/echo "1" > =
/proc/sys/net/ipv4/conf/all/log_martians
> # W kernelu 2.4 nie trzeba wlaczac =
opcji ip_always_defrag
>
> W linii 2 informujemy nasz ruter, =
aby nie odpowiadał na zapytania ICMP
echo - czyli ruter nie będzie odpowiadał na =
pingi.
>
> W linii 4 uniemożliwiamy =
odpowiedzi ICMP echo na pakiety typu broadcast
w efekcie czego bronimy się przed atakiem typu =
Smurf. Atak ten polega na
tym, że atakujący wysyła pakiety ICMP echo =
request skierowane na adresy
broadcastowe naszej sieci. Wszystkie komputery naszej =
sieci odpowiadaja na
takie pakiety co najczęściej powoduje silne =
przeciążenie sieci. Bardzo
często adres źródłowy takiego pakietu jest =
zmieniony i ustawiony na
rzeczywistą ofiarę, która otrzymuje nagle =
echo-reply. Jeśli w ten sposób zostanie =
zaatakowanych kilka podsieci, łącze
ofiary może ulec zapchaniu.
>
> W linii 6 powiadamiamy jądro =
systemu, aby nie akceptowało pakietów
"source routed". Atakujący może =
użyć tego typu pakietów, aby udawać, że jest
z wnętrza naszej sieci, lecz ruch ten byłby =
kierowany spowrotem wzdłuż
ścieżki po której do nas dotarł. Technika ta =
rzadko jest używana w
uzasadninych celach.
>
> W linii 8 zabraniamy zmieniania =
naszej tablicy rutingu na podstawie
pakietów ICMP redirect.
>
> W linii 10 powodujemy, że nasz =
host nie będzie reagował na fałszywe
komunikaty o błędach.
>
> Standardowym mechanizmem jest =
nie znajdujących się w naszej tablicy rutingu, co =
odbywa się w linii 12.
Oznacza to, że jeśli na karcie eth1 jest =
zdefiniowana sieć 192.168.1.0/30 to
nie przyjmie ona pakietów z adresu 10.1.23.32. =
Oczywiście karta eth0 będzie
przyjmowała wszystkie pakiety, ponieważ jest =
poprzez nią dostęp do naszego
gatewaya (rutera).
>
> Linia 14 powoduje, że informacja o =
wszelakich dziwnych (podejrzanych)
pakietach znajdzie się w logach systemowych.
>
> iptables -A INPUT -i lo -j =
ACCEPT
> iptables -A OUTPUT -o lo -j =
ACCEPT
>
> Pierwsze co umożliwiamy to ruch na =
urządzeniu lo, które jest
wykorzystywane przez różne procesy lokalne. Na =
ten ruch nie stawiamy żadnych
ograniczeń.
>
> Poniżej tworzymy nowy łańcuch =
o nazwie syn-flood który będzie
zabezpieczał nasz ruter przed atakami typu DoS. =
Oczywiście jest bardzo
prawdopodobne, że bedziesz musiał dobrać =
(najczęściej eksperymentalnie)
czułość działania modułu limit.
>
> iptables -N syn-flood
> iptables -A INPUT -i eth0 -p tcp =
--syn -j syn-flood
> iptables -A syn-flood -m limit =
--limit 1/s --limit-burst 4 -j RETURN
> iptables -A syn-flood -j LOG =
--log-level debug --log-prefix "IPT
SYN-FLOOD: "
> iptables -A syn-flood -j DROP
>
> W pierwszej linii tworzymy =
łańcuch syn-flood. W drugiej linii
powodujemy, że wszystkie pakiety protokołu TCP z =
ustawioną flagą syn
pojawiające się na karcie sieciowej eth0 i =
wędrujace przez łańcuch INPUT
(skierowane bezpośrednio do naszego rutera) =
będą skierowane do łańcucha
syn-flood. Pakiety z ustawioną flagą syn (i w =
poprawnym połączeniu również
ack) służą do nawiązywania połączenia. W =
linii 3 zaczynamy "zliczanie" tych
pakietów. Jeżeli pojawi się więcej niż =
jeden na sekundę pakiet nawiązujący
połączenie z naszym ruterem, to po czterech =
takich pakietach reguła 3
przestanie przerzucać pakiety spowrotem (-j RETURN) =
takim wypadku zostaną wykonane następne =
regułki. Reguła 4 spowoduje że
informacja o takim pakiecie pojawi się w logach =
systemowych z przedrostkiem:
"IPT SYN-FLOOD: ". Reguła 5 spowoduje, =
że pakiet taki zostanie skasowany bez
żadnej dodatkowej reakcji ze strony naszego hosta =
TCP/IP. Przydało by się
jeszcze ustawić ograniczenie limit na =
> pakietów zapisywaną do logów, bo w =
przypadku ataku DoS może nam się dysk
trochę przepełnić, zwłaszcza że system =
może nie nadążyć zapisywać tego do
logów. Poprawna postać linii nr 4: iptables -A =
syn-flood -m limit --limit
1/s --limit-burst 4 -j LOG --log-level debug =
--log-prefix "IPT SYN-FLOOD: ".
Tutaj też możemy poeksperymentować z =
wartościami parametrów.
>
> iptables -A INPUT -i eth0 -p icmp -m =
state --state
ESTABLISHED,RELATED -j ACCEPT
> iptables -A OUTPUT -o eth0 -p icmp =
-m state --state
NEW,ESTABLISHED,RELATED -j ACCEPT
>
> Powyższe linijki zapewniają nam =
przepuszczanie nawiązanych połączeń
protokołu icmp (linia 1) i nawiązywanie =
połączeń pochodzących z naszego
hosta (linia 2).
>
> iptables -A INPUT -i eth0 -p tcp ! =
--syn -m state --state NEW -j
LOG --log-level debug --log-prefix "IPT NEW: =
"
> iptables -A INPUT -i eth0 -p tcp ! =
--syn -m state --state NEW -j DROP
>
> Powyższe linie wynikają z pewnej =
niekonsekwencji w implementacji modułu
conntack służącego do śledzenia =
połączeń w pakiecie netfilter. Moduł ten
uznaje pakiety TCP bez flagi syn, a z ustawioną =
flagą ack za kontynuujące
połączenie i są one uznawane za pakiety NEW =
1 z powyższych linijek logujemy (zapisujemy do =
logów) pakiety uznane za NEW
(--state NEW) bez ustawionej flagi syn ( ! --syn ). W =
kolejnej linii
porzucamy takie pakiety.
>
> iptables -A INPUT -i eth0 -f -j LOG =
--log-level debug --log-prefix "IPT
FRAGMENTS: "
> iptables -A INPUT -i eth0 -f -j =
DROP
>
> Podobna konstrukcja zastosowana jest =
w powyższych regułkach. Pakiety
sfragmentowane -f na wszelki wypadek (atak Jolt2) =
porzucamy, oczywiście
uprzednio je logując. Jeśli w logach systemowych =
będziemy mieli wiele
informacji o takich pakietach, to będziemy musieli =
wyłączyć te reguły.
>
> Poniżej mamy małe zabezpieczenie =
anty-spoofingowe (przeciw podszywaniu
się pod inne adresy niż własne). W sumie =
niepotrzebne, ale nigdy nie wiadomo
czy nasz stos TCP/IP nie ma jeszcze nie wykrytych =
błędów.
>
> #Pakiety z adr. zrodlowym ustawionym =
na nasz.
> iptables -A INPUT -i eth0 -s =
111.222.333.444 -j DROP
> iptables -A INPUT -i eth0 -d =
127.0.0.0/8 -j DROP # na eth0 do
loopbacka?
> iptables -A INPUT -i eth0 -d =
111.222.333.255 -j DROP # broadcasty
> iptables -A INPUT -i eth1 -p udp -d =
192.168.1.255 --dport 137:138 -j
DROP
>
> Powyższe regułki nie powinny =
nastręczać wątpliwości. Na karcie eth0 nie
powinny się pojawić pakiety z pochodzące =
z:
>
> linia 2: pakiety z adresu interfejsu =
wewnętrznego lo
> linia 3: poza tym wycinamy pakiety =
skierowane do wszystkich komputerów w
naszej podsieci - najczęściej nie są zbyt =
wyremować tą linijkę.
> Niestety najczęściej komputer =
którego bedziemy używali w naszej sieci
lokalnej, będzie miał system operacyjny pewnej =
znanej wszystkim firmy.
System ten silnie "śmieci" (wysyła =
wiele broadcastów IP protokołu UDP na
porty 137 i 138) w wyniku enkapsulacji protokołu =
NetBIOS wewnątrz protokołu
IP. Mam nadzieję, że wyłączyliscie =
protokół NetBIOS na karcie swojego
komputera lokalnego? Abyśmy nie mieli logów =
systemowych zarzuconych
informacjami o działalności tego protokołu, =
wpisujemy ostatnią z powyższych
regułek. I w końcu dochodzimy do regułek =
możliwe do naszego komputera.
>
> # lancuch INPUT
> iptables -A INPUT -p tcp --sport =
1024: --dport 22 -m state --state
NEW -j ACCEPT # ssh na obu kartach
> iptables -A INPUT -p tcp --sport =
1024: --dport 113 -m state --state
NEW -j REJECT --reject-with =
> iptables -A INPUT -m state --state =
ESTABLISHED,RELATED -j ACCEPT
> iptables -A INPUT -j LOG --log-level =
> iptables -A INPUT -j DROP
>
> Ponieważ w powyższych =
regułkach nie zdefiniowałem interfejsu sieciowego,
będą one działały na obu kartach sieciowych w =
naszym ruterze. W drugiej
linijce definiujemy regułkę mówiącą: =
pakiety protokołu tcp pochodzące z
portów powyżej 1023 skierowane na port 22 (ssh) i =
uznane za NEW, czyli
nawiazujące połączenie akceptujemy. Pozostałe =
pakiety dla połączenia
nawiązanego za pomocą pakietu przepuszczonego =
przez regułkę nr 2 zostana
przepuszczone przez regułkę w linii 4. Mówi =
ona: pakiety które uznasz za
należące (ESTABLISHED) lub związane (RELATED) z =
juz istniejącym połączeniem
zaakceptuj. Pakiety nie zaakceptowane przez te =
regułki zostaną zalogowane
(regułka nr 5) i usunięte (regułka nr 6). =
Oczywiście gdyby nie było regułki
nr 6 to zadziałała by polityka łańcucha INPUT =
ustawiona równiez na DROP ale
troche paranoi nikomu nie zaszkodzi. Gdybyśmy =
uruchomili na naszym ruterze
serwer WWW (czego oczywiście ze względów =
bezpieczeństwa nie polecam)
wystarczyłoby skopiować regułkę nr 2, =
!
> wkleić poniżej tej regułki (w linii =
poprzedzającej regułkę 4) i zmienić
wartość portu 22 na 80. Przypominam, że numery =
portów znajdziesz w pliku
/etc/services. Do wytłumaczenia pozostaje regułka =
nr 3. Bardzo czesto różne
serwery usług (np ftp) pytają się hosta z =
którego sie łączymy o nasze dane
za pomocą usługi ident działającej na porcie =
113. Jeżeli nie byłoby regułki
3, przykładowy serwer FTP wysłałby pakiet na =
port 113 naszego rutera i
czekał na odpowiedź. Ponieważ pakiet ten =
zostałby skasowany, nie otrzymałby
żadnej odpowiedzi. W końcu otrzymalibyśmy zgode =
na połączenie, ale czas
oczekiwania byłby dosyć długi. W linii 3 =
powodujemy, że na zapytania na port
113 protokołu TCP generowany jest pakiet =
protokołu ICMP z komunikatem:
icmp-port-unreachable. Serwer FTP jest poinformowany =
że na naszym hoście
usługa ident nie działa i juz bez dalszej =
zwłoki pozwala nam się zalogować.
Zwróć również uwagę że dla protokołu =
UDP nie zostały zdefiniowane żadne
regułki, ponieważ nie udostęp!
> niamy żadnych usług korzystających z tego =
protokołu. tak napr!
> awde to udostepniamy jedynie ssh. Bardzo =
polecane byłoby zawężenie
działania regułki 2 poprzez podanie numeru IP =
komputera z którego
umożliwiamy połączenia na ssh.
>
> # lancuch OUTPUT
> iptables -A OUTPUT -m state --state =
! INVALID -j ACCEPT
> iptables -A OUTPUT -j LOG =
--log-level debug --log-prefix "IPT OUTPUT: "
> iptables -A OUTPUT -j DROP
>
> W tym łańcuchu powinniśmy =
również powinniśmy dokładnie zdefiniować
połączenia które można nawiązywać z =
naszego rutera. Jednak w ten sposób sami
sobie ograniczalibyśmy funkcjonalność naszego =
hosta. W przypadku
profesjonalnego rutera dla większej podsieci nie =
należy zostawiać niczego
przypadkowi, ale w naszym przypadku nie będziemy =
tacy dokładni. Regułka 2
akceptuje wszystkie poprawne pakiety. Składnia =
--state ! INVALID oznacza
wszystkie pakiety nie zakwalifikowane jako NEW, =
ESTABLISHED ani RELATED.
czyli uszkodzone. Regułka 3 powoduje logowanie =
odrzuconych pakietów,a
regułka 4 ich usunięcie.
>
> # lancuch forward
> iptables -A FORWARD -i eth1 -p tcp =
-s 192.168.1.0/30 --sport 1024: -m
state --state NEW,ESTABLISHED,RELATED -j =
ACCEPT
> iptables -A FORWARD -i eth1 -p udp =
-s 192.168.1.0/30 --sport 1024: -m
state --state NEW,ESTABLISHED,RELATED -j =
ACCEPT
> iptables -A FORWARD -o eth1 -p tcp =
-d 192.168.1.0/30 --dport 1024: -m
state --state ESTABLISHED,RELATED -j ACCEPT
> iptables -A FORWARD -o eth1 -p udp =
-d 192.168.1.0/30 --dport 1024: -m
state --state ESTABLISHED,RELATED -j ACCEPT
> iptables -A FORWARD -p icmp -m state =
--state ! INVALID -j ACCEPT
> iptables -A FORWARD -j LOG =
--log-level debug --log-prefix "IPT FORWARD:
"
> iptables -A FORWARD -j DROP
>
> W łańcuchu FORWARD definiujemy =
regułki dotyczące pakietów wędrujących
poprzez nasz ruter. Regułki 2 i 3 oznaczają: dla =
protokołów TCP i UDP
wchodzących na kartę eth1 ( -i eth1 ) z sieci =
lokalnej 192.168.1.0/30 z
portów powyżej 1023 przepuść pakiety =
nawiązujące połączenia, pakiety
należące do istniejących połączeń i =
pakiety związane z istniejącymi
połączeniami. Oznacza to że z sieci lokalnej =
możemy nawiązywac połączenia.
Regułki 4 i 5 oznaczają: dla protokołów TCP i =
UDP wychodzących z karty eth1
( -i eth1 ) do sieci lokalnej 192.168.1.0/30 na porty =
powyżej 1023 przepuść
pakiety należące do istniejących połączeń =
połączeniami. W domysle nie przepuszczaj =
pakietów nawiązujących połączenia.
Regułka 6 pozwala na niczym nie ograniczony ruch =
poprawnych pakietów
protokołu ICMP. Jeśli pojawią się jakieś =
pakiety nie należące do
istniejącego połączenia, nie zostaną one =
przepuszczone. Ostatnie dwie
regułki, standardowo logują i wycinają =
wszystkie pozost!
> ałe pakiety.
>
>
> =
-------------------------------------------------------------------------=
-
----
>
> Tworzenie firewalla - =
końcówka.
>
> W tym momencie mamy działającego =
poprawnie firewalla. Należy tylko
obserwować logi systemu i patrzeć co jest =
wycinane przez nasze regułki.
Każdy wycięty pakiet będzie opatrzony =
przedrostkiem który zdefiniowaliśmy w
regułkach --log-prefix "IPT FORWARD: " i =
się dzieje coś niedobrego. Przydało by się, =
abyśmy informacje o działaniu
firewalla mieli w logach. W tym celu wpisujemy na =
koniec pliku
/etc/syslog.conf coś takiego:
>
> =
*.* =
/dev/tty12
> =
*.* =
/var/log/all
>
> i oczywiście restartujemy demona =
syslogd:
>
> # killall -HUP syslogd
>
> od tego momentu w pliku /var/log/all =
(oraz na konsoli12 - Alt+F12)
będziemy mieli wszystkie logi systemowe. Należy =
uważać aby logi nam nie
zapchały twardego dysku, czyli należy =
skonfigurować logrotate, ale to
oczywiście znajdziecie już na stronach =
>
> =
------------------------------------------------------------------=
----
> =
Poznam mila dziewczyne w celu... >>> http://link.interia.pl/f16f8
>
>