Organizacja i konfiguracja rutera w sieci LAN ( pppoed + dhcpd, na przykladzie FreeBSD : ipfw
+ dummynet + natd )
v.0.2-ALPHA
1) Zaczniemy od serwera DHCP :
- Co to DHCP ?
DHCP (ang. Dynamic Host Configuration Protocol) to protokół komunikacyjny umożliwiający komputerom uzyskanie od serwera danych konfiguracyjnych, np. adresu IP
hosta, adresu IP bramy sieciowej, adresu serwera DNS, maski sieci. Protokół DHCP jest zdefiniowany w RFC 2131 i jest następcą BOOTP. DHCP został opublikowany jako standard w roku 1993. W kolejnej generacji protokołu IP czyli IPv6 jako integralną część dodano nową wersję DHCP czyli DHCPv6. Jego specyfikacja została opisana w RFC 3315.
Przydzielanie adresów IP:
Protokół DHCP opisuje trzy techniki przydzielania adresów IP:
* przydzielanie ręczne oparte na tablicy adresów MAC oraz odpowiednich dla nich adresów IP. Jest ona tworzona przez administratora serwera DHCP. W takiej sytuacji prawo do pracy w sieci mają tylko komputery zarejestrowane wcześniej przez obsługę systemu.
* przydzielanie automatyczne, gdzie wolne adresy IP z zakresu ustalonego przez administratora są przydzielane kolejnym zgłaszającym się po nie klientom.
* przydzielanie dynamiczne, pozwalające na ponowne użycie adresów IP. Administrator sieci nadaje zakres adresów IP do rozdzielenia. Wszyscy klienci mają tak skonfigurowane interfejsy sieciowe, że po starcie systemu automatycznie pobierają swoje adresy. Każdy adres przydzielany jest na pewien okres czasu. Taka konfiguracja powoduje, że zwykły użytkownik ma ułatwioną pracę z siecią.
Niektóre serwery DHCP dodatkowo przydzielają każdemu klientowi własny adres DNS, przekazywany na serwer nazw protokołem zgodnym ze specyfikacją RFC 2136
Niektóre z dodatkowych opcji:
* adres IP serwera DNS
* nazwa DNS
* adres IP bramy sieciowej (ang gateway)
* adres broadcast
* maska podsieci
* maksymalny czas oczekiwania na odpowiedź w protokole ARP
* wartość MTU (maksymalny rozmiar pakietu)
* adresy serwerów NIS
* Domena NIS
* adres IP serwera SMTP
* Adres serwera TFTP
* Adres serwera nazw Netbios
Microsoft wprowadził DHCP do systemu Windows NT w wersji 3.5 w roku 1994, jednak to nie ta firma opracowała sam protokół.
Fundacja Internet Software Consortium opracowała serwer DHCP w wersji 1.0.0. dla systemów Unix. ISC DHCP został wydany 6 grudnia 1997 roku, a w 1999 pojawiła się wersja 2.0 bardziej zgodna ze specyfikacją.
Serwer ten jest dostępny na stronie: http://www.isc.org/sw/dhcp/
Korporacja Cisco opracowała własny serwer DHCP dla systemu IOS 12.0 w roku 1999. System
operacyjny Solaris firmy Sun został wyposażony w pełną obsługę protokołu w roku 2001.
Niektórzy producenci ruterów rozszerzyli ich możliwości o obsługę serwera DHCP
Darmowy serwer DHCP dla systemu Windows jest dostępny na stronie:
http://tftpd32.jounin.net/
- Dlaczego tak naprawde DHCP ma byc w mojej sieci ?
Jezeli zarzadzasz siecia lokalna, gdzie ilosc komputerow jest duza ( > 10 ) sensownym bedzie uruchomic serwer DHCP, ma to swoje wady i zalety:
ZALETY:
a) Nie musisz wpisywac "recznie" adresow IP klientom (najwiekszego znaczenia nabiera przy sieciach, powyzej 20 komputerow - prosze sobie wyobrazic bieganie do 120 klientow i ustawianie im IP...) - wszystkim sterujesz zdalnie "od siebie"
b) Jezeli klient ma zawirusowany komputer, ktory rozsyla wirusy na caly swiat, bombarduje pakietami inne komputery lub inne podobne - odpisujemy MAC jego komputera z DHCP, restartujemy serwer DHCP, po czasie ktory okreslilismy w konfigu klient straci swoje IP
i wirus przestanie sie rozsylac, nie majac polaczenia. Dajemy znac Zenkowi ze ma wirusa i ze ma zrobic porzadek z komputerem, dopiero wtedy go podlaczymy.
( To powinno zadzialac nawet na tych najbardziej "upartych" klientow ktorzy czesto otrzymujac od nas telefon, sa oburzeni, obrazeni - przeciez ich komputer nie moze miec wirusa :) ) WADY:
a) Zalozmy, ze nasz serwer DHCP juz dziala, przypisuje klientom poprawne IP, klienci maja internet od nas i sa zadowoleni. Pewnego dnia pojawia sie "abuser" (to taka osoba lubiaca psocic) w sieci i uruchamia drugi serwer DHCP w sieci lokalnej... Albo inna sytuacja -
moze nasz klient wlaczy przez przypadek/niewiedze drugi serwer DHCP. Co wtedy sie dzieje? Z
ktorego serwera DHCP komputery beda pobierac IP ? Obowiazuje tutaj zasada "kto pierwszy ten lepszy" - czyli zalozmy komputer Zenka chce pobrac IP, wysyla zapytanie do sieci i czeka na odpowiedz... Nasz serwer DHCP, jak i ten "niepowolany" przyjmuja zgloszenia i jezeli znajda jakies reguly w konfiguracji dla tego komputera - odpowiadaja komputerowi Zenka na zapytanie. Niestety komputer Zenka przyjmie tylko jedna odpowiedz - ta, ktora pierwsza dotrze do niego. Dla nas administratorow jest to dosyc trudny problem - niektorzy uwazaja ze problemu nie ma - "idz i odetnij/wyciagnij kabel ze switcha "abuserowi" (ten co cos nam psuje w sieci) i niech zaplaci kare". O ile nalozenie kary za taki wyczyn to kwestia umowy, ktora podpisuje uzytkownik przy podlaczeniu do sieci, to i tak ciezko taka osobe zlokalizowac - gdy spoofoje dodatkowo adres MAC... A majac duza siec rozpieta na kilka budynkow - wyobrazcie sobie ile czasu stracicie na bieganine...
No to do dziela :)
Mamy juz sciagniety, rozpakowany serwer ISC DHCP na UNIXie, teraz standardowo:
./configure
make
make install
Nasza sytuacja:
interfejsy:
rl0 - sieciowka do LAN 192.168.0.0/24
rl1 - sieciowka do modemu DSL TPSA 83.16.13.166/32 - aan166.internetdsl.tpnet.pl Oto przykladowy plik konfiguracyjny serwera ISC DHCP - bazowany na metodzie przydzielania po adresie MAC , plik ten najczesciej jest zlokalizowany w /etc/dhcpd.conf :
-- Start /etc/dhcpd.conf -
#
option domain-name "aan166.internetdsl.tpnet.pl";
# nasz host
option domain-name-servers 193.110.120.5, 194.204.159.1; # serwery DNS, ktorymi beda
option subnet-mask 255.255.255.0;
#maska sieci
option netbios-name-servers 192.168.0.30;
# serwer WINS
option netbios-node-type 8;
# kolejnosc odpytywania nazw NETBIOSu
default-lease-time 10000;
# czas dzierzawy - na jak dlugi czas ma byc przyznane IP w
sekundach
max-lease-time 10800;
# maksymalny czas dzierzawy IP
ddns-update-style none;
# ustawienia wspolpracy DHCP z serwerem nazw
option broadcast-address 192.168.0.255;
# broadcast sieci
option routers 192.168.0.1;
# IP routera (czyli IP naszego serwa)
subnet 192.168.0.0 netmask 255.255.255.0
# podsiec ktorej serwer DHCP ma
odpowiadac
{
}
# przykladowe wpisy MACow naszych klientow z LAN:
host irek {hardware ethernet 00:e0:18:64:63:32; fixed-address 192.168.0.2;}
host zosia {hardware ethernet 00:02:44:56:16:91; fixed-address 192.168.0.3;}
host kowalski
{hardware ethernet 00:50:fc:a1:9f:16; fixed-address 192.168.0.4;}
host bartek {hardware ethernet 00:50:fc:a1:9f:10; fixed-address 192.168.0.5;}
#
--EOF
ISC DHCP uruchamiamy komenda :
dhcpd
pozniej mozna 'dhcpd -q' aby nie smiecilo w logach ( -q == --quiet (cicho) ), warto rowniez sie rozejrzec za innymi ciekawymi udogodnieniami w 'man dhcpd'
Sprawdzamy czy nasz serwer chociaz sie wlaczyl :
ps aux |grep dhcpd
I wypadaloby sprawdzic czy przydziela klientom LANu to co wpisalismy, pamietajac ze po wprowadzeniu jakichkolwiek poprawek w /etc/dhcpd.conf musimy zrestartowac serwer, np.
taka komenda :
killall -KILL dhcpd && dhcpd -q
Wygodnie jest dodac do jakiegos autostartu ta komende, np. w pliku
/usr/local/etc/rc.d/rc.local.sh :
--- /usr/local/etc/rc.d/rc.local.sh
dhcpd -q &
--- EOF
Testujemy restartujac
Dziala ? Ok, idziemy dalej, jezeli nie, no to czytamy nasze logi :
tail -f /var/log/messages
Szukamy bledu, poprawiamy, jak nie pomoze :
http://www.dhcp-handbook.com/dhcp_faq.html
2) NAT z limitowaniem transferu, przekierowania portow- Czyli udostepnianie lacza innym...
NAT (ang. Network Address Translation) - Jest to technika translacji adresów sieciowych.
Wraz ze wzrostem ilości komputerów w Internecie, zaczęła zbliżać się groźba wyczerpania puli dostępnych adresów internetowych IPv4.
Aby temu zaradzić, lokalne sieci komputerowe, korzystające z tzw. adresów prywatnych (specjalna pula adresów tylko dla sieci lokalnych), mogą zostać podłączone do Internetu przez jeden komputer (lub router), posiadający mniej adresów internetowych niż komputerów w tej sieci.
Router ten, gdy komputery z sieci lokalnej komunikują się ze światem, dynamicznie tłumaczy adresy prywatne na adresy zewnętrzne, umożliwiając użytkowanie Internetu przez większą liczbę komputerów niż posiadana liczba adresów zewnętrznych.
Z korzystaniem z Internetu poprzez NAT wiążą się wady:
* nie można na własnym komputerze uruchomić serwera dostępnego w Internecie,
* utrudnione korzystanie z programów P2P i bezpośredniego wysyłania plików.
Zaletą takiego systemu jest większe bezpieczeństwo komputerów znajdujących się za NAT-em.
NAT jest często stosowany w sieciach korporacyjnych (w połączeniu z proxy) oraz sieciach osiedlowych.
Można wyróżnić 2 podstawowe typy NAT:
* SNAT (Source Network Address Translation) to technika polegająca na zmianie adresu źródłowego pakietu IP na jakiś inny. Stosowana często w przypadku podłączenia sieci dysponującej adresami prywatnymi do sieci Internet. Wtedy router, przez którego podłączono sieć, podmienia adres źródłowy prywatny na adres publiczny (najczęściej swój własny).
* DNAT (Destination Network Address Translation) to technika polegająca na zmianie adresu docelowego pakietu IP na jakiś inny. Stosowana często w przypadku, gdy serwer mający być dostępny z Internetu ma tylko adres prywatny. W tym przypadku router dokonuje translacji adresu docelowego pakietów IP z Internetu na adres tego serwera.
Szczególnym przypadkiem SNAT jest maskarada mająca miejsce, gdy router ma zmienny adres IP (np. otrzymuje go w przypadku połączenia modemowego wdzwanianego). Wtedy router zmienia adres źródłowy na taki, jak adres interfejsu, przez który pakiet opuszcza router.
Systemy operacyjne maja zaimplementowany NAT :
- Linux - za pomocą pakietu iptables, czy starszego ipchains
- BSD - pf
- FreeBSD - natd
konfiguracja NATu na przykladzie FreeBSD serii 4.x (natd, ipfw, dummynet): Nasza sytuacja:
interfejsy:
rl0 - sieciowka do LAN 192.168.0.0/24
rl1 - sieciowka do modemu DSL TPSA 83.16.13.166/32 - aan166.internetdsl.tpnet.pl Jezeli robisz NAT na FreeBSD pierwszy raz - odpusc sobie na razie kompilacje kernela - ona nam bedzie potrzebna pozniej do bardziej zaawansowanych opcji, dla samego NATu kernel
GENERIC - ten defaultowy w zupelnosci wystarcza)
{ --- Tekst o kompilacji kernela
Przekompilowujemy kernel GENERIC dodajac do niego kilka opcji :
( opis kompilacji kernela jest dobrze opisany na http://freebsd.hello.pl ) cd /usr/src/sys/i386/conf
cp GENERIC KUCZEK
ee KUCZEK # ee - defaultowy edytor we FreeBSD, podobny do joe z Linuxa
Idziemy na koniec pliku i dopisujemy :
options MROUTING
options IPFIREWALL
options IPFIREWALL_VERBOSE
options IPFIREWALL_FORWARD
options IPFIREWALL_DEFAULT_TO_ACCEPT
options IPV6FIREWALL
options IPV6FIREWALL_VERBOSE
options IPV6FIREWALL_DEFAULT_TO_ACCEPT
options IPDIVERT
options IPSTEALTH
options TCPDEBUG
options DUMMYNET
options BRIDGE
options IPFW2
options DEVICE_POLLING
options HZ=1000
Teraz kompilujemy nowe jadro, instalujemy :
cd /usr/src
make buildkernel KERNCONF=KUCZEK
make installkernel KERNCONF=KUCZEK
i reboot - jak wlaczy sie to gratulacje, jezeli z jakichs powodow nie - bootujemy ze starego kernela (kernel.old)
w dmesg mozemy posprawdzac czy nie ma jakichs dziwnych errorow ( nie zawsze sie wszystko dobrze skompiluje... )
jezeli wszystko ok, idziemy dalej :
} ----- Koniec tekstu o kompilacji kernela
Konfigurujemy sobie prosty NAT - zapisujemy sobie w pliku /etc/rc.firewall ciag komend:
-- Start /etc/rc.firewall
# ustawienia sciezki do programu ipfw - skrot od IP Firewall:
fwcmd="/sbin/ipfw"
# wyczyszczenie regul :
${fwcmd} -f flush
${fwcmd} -f pipe flush
${fwcmd} -f queue flush
${fwcmd} zero
# regula odpowiedzialna za dzialanie zwyklego, najprostszego NATu (przepuszcza obojetnie jaki ruch):
${fwcmd} add 50 divert natd all from any to any
--- Koniec /etc/rc.firewall
Skladnia tej ostatniej reguly jest dosyc intuicyjna, jest ona odpowiedzialna za wyslanie do programu 'natd' pakietow przeznaczonych do NATowania. natd to juz wlasciwy program, ktory obsluzy nam NAT.
Dodajemy do autostartu - w pliku /etc/rc.conf dodajemy/edytujemy:
gateway_enable="YES"
firewall_enable="YES"
firewall_script="/etc/rc.firewall"
firewall_type="OPEN"
firewall_logging="YES"
firewall_flags=""
Konfiguracja natd :
Prawie cale natd skonfigurujemy w pliku /etc/rc.conf , wyedytujmy go :
ee /etc/rc.conf
i dodajmy lub edytujmy linijki :
natd_enable="YES"
natd_program="/sbin/natd"
natd_interface="rl1"
natd_flags="-f /etc/natd.conf"
teraz tworzymy sobie plik :
touch /etc/natd.conf
w nim bedziemy przechowywac dodatkowe reguly NATowania - takie jak np. przekierowania portow - o tym za chwile, na razie zostawiamy pusty plik.
Restartujemy i testujemy ...
Mamy juz skromny firewall i poustawiany prosty NAT :)
Teraz mozemy dodac konfiguracje "ciecia lacza", jezeli opusciles "kompilacje kernela" - to jest ten czas kiedy trzeba by to zrobic ...
Jestesmy juz po rekompilacji kernela, mamy w nim obsluge "dummynet" - jest to "dodatek" do programu ipfw realizujacy regulowanie przeplywu danych.
Nasz plik /etc/rc.firewall proponuje sobie zbackupowac przed dalszymi zmianami.
Dodajemy do tego pliku nastepujace reguly zapisane w petlach (niezrozumiale? zapraszam na wyklad o skryptach w shellu :) ) :
# klienci z downloadem 12KB/s - reguly dummynetu
for i in 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 50
do
${fwcmd} pipe $i config bw 12KBytes/s
${fwcmd} add 200$i pipe $i tcp from not 192.168.0.0/24 to 192.168.0.$i in
# klienci z wysylaniem 6KB/s
for i in 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 50
do
${fwcmd} pipe 10$i config bw 6KBytes/s
${fwcmd} add 50$i pipe $i tcp from 192.168.0.$i to not 192.168.0.1 via rl0
done
... no i juz. probojemy zrestartowac i sprawdzamy, czy kazdy z klientow moze sie cieszyc (czy plakac?) naszym internetem (12 KB/s download, 6 KB/s upload)
Do tego mozemy jeszcze dolozyc przekierowania portow. Istnienie takiej potrzeby jest wyjasnione wyzej, przy objasnianiu NATu.
Zalozmy, ze chcemy przekierowac port 6666 z naszego internetowego interfejsu rl1 na komputer 192.168.0.10 w LAN.
Wystarczy dodac te linijki do pliku ktory wczesniej stworzylismy, przy ustawianiu konfiguracji programu natd - do /etc/natd.conf :
-- (...) /etc/natd.conf
redirect_port tcp 192.168.0.10:6666 6666
redirect_port udp 192.168.0.10:6666 6666
--- EOF
restartujemy i... juz?
Inne ciekawe opcje podobne do 'redirect_port' znajdziecie w opisie programu natd ( man natd )
3. MAC spoof - czyli zaczynaja sie problemy z userami-psotnikami
(czesc trudniejsza do wykonania)
Jak wiemy w wiekszosci konfiguracji routerow komputer klienta rozpoznajemy po adresie MAC
jego karty sieciowej - kazda karta sieciowa ma swoj unikatowy MAC, nie ma takiej drugiej.
Jednak bardzo latwo mozna oszukac komputer, podajac "podstawiony" MAC naszej karty sieciowej (taka operacja powszechnie jest znana w internecie jako "ARP spoof" lub "MAC spoof"
). Praktycznie na kazdym systemie operacyjnym mozna to wykonac bez problemu, w linuxie czy freebsd 3-4 komendami, w windowsach, 5 kliknieciami... Zastanowmy sie - co to oznacza tak naprawde dla nas - administratorow sieci LAN. Ano tylko to, ze nasi uzytkownicy nie moga byc rozpoznawani tylko po MACu karty sieciowej, skoro tak latwo jest go sobie "podmienic".
Jednym z rozwiazan jest wprowadzenie dodatkowego polaczenia pomiedzy klientem LANu a serwerem - polaczenia PPPoE
PPPoE - Point-to-Point Protocol over Ethernet - jest polaczeniem dwoch protokolow - PPP i ETHERNET, czesto wykorzystywany przez krajowych providerow, np. w laczach neostrady TPSA Dla nas najbardziej istotna rzecza w tej technologii jest to - ze komputer uzytkownika bedzie autoryzowany na serwerze haslem dostepu - ktore uzywa sie przy polaczeniach PPPoE
A wiec musi miec 1 serwer polaczen PPPoE, klienci w LAN musza miec doinstalowane protokoly PPPoE (klienckie), nasz firewall trzeba troszke przekonfigurowac...
Serwer polaczen "PPPoE" na przykladzie FreeBSD:
tun0, tun1 ... tunx - wirtualne interfejsy utworzone przy polaczeniu PPPoE klienta z LAN do
UWAGA: domyslnie w konfiguracji systemu FreeBSD maksymalna ilosc naraz otwartych takich polaczen jest mala (1-4) (trzeba utworzyc kolejne tun3, tun4 itd. - dokladne informacje o tym jak to zrobic w manualu FreeBSD )
Najtrudniejsze i tak bedzie skonfigurowanie pierwszego polaczenia, pozniej to juz "male piwo", a wiec ruszamy ...
do pliku /boot/loader.conf dopisujemy:
netgraph_load="YES"
potrzebne dla pppoed (szczegoly man pppoed)
program pppoed jest serwerem polaczen PPPoE - nasluchuje i w razie polaczenia uruchamia program ppp z odpowiednimi opcjami, a wiec jest scisle z nim powiazany...
Edytujemy /etc/ppp/ppp.conf, ma on wygladac mniej wiecej tak :
-- START pliku
default:
NECIK:
allow mode direct # Only for use on server-side set mru 1492 # Max allowed by the PPPoE spec set mtu 1492 # Max allowed by the PPPoE spec set speed sync # PPPoE is always synchronous enable proxy # Proxy ARP
enable chap # Force client authentication disable pap # Don't send password in the clear
# Control the compression protocol used by disabling anything we DON'T want disable mppe # Disable mppe to ensurecompression deny mppe # Also deny it if they ask for it disable deflate # Disable deflate compression deny deflate # Also deny it if they ask for it set timeout 0 # No idle timeout for PPP!
accept dns # Allow DNS negotiation
set cd 5 # PPPoE uses "carrier" detect enable lqr # Re-establish broken connections set lqrperiod 15 # Check the link often
set log +ccp # Log compression negotiations
--- EOF
Sa ta opcje dla naszych polaczen, ktore nazwalem sobie NECIK
Teraz w pliku /etc/ppp/ppp.secret musimy dodac naszych userow i ich hasla, oto przykladowe wpisy:
# Authname Authkey
Peer's IP address
Label Callback
franek pass_franka 192.168.1.2/32 * *
jozek
pas_jozka
192.168.1.3/32 * *
#
na koniec tworzymy sobie plik /usr/local/etc/rc.d/rc.pppoed.sh , ktory ma zawierac:
#
(...)
/usr/libexec/pppoed -P /var/ppp.pid -a NECIK -e '/usr/sbin/ppp -direct NECIK ' -p '*' rl0
#
To na potrzeby autostartu...
To by bylo na tyle jesli chodzi o sam serwer pppoe, teraz przydaloby sie dostosowac nasz firewall - zeby wycinal internet tym - ktorzy zle wpisza haslo, lub nie nawiaza polaczenia pppoe z naszym serwerem
Edytujemy nasz plik z firewallem - /etc/rc.firewall i dodajemy linijke :
${fwcmd} add 49 deny ip from 192.168.0.2 to not 192.168.0.1 via rl0
Ta regula odrzuci wszystkie pakiety od 192.168.0.2 na interfejsie rl0 idace w swiat.
Zauwazmy, ze nawiazujac polaczenie PPPoE klient ma IP z nowej podsieci - 192.168.1.0/24
Takie pakiety sa juz na innym interfejscie - tun0 lub na tun1 itp. wiec - problem mamy rozwiazany. Jezeli klient nie nawiaze polaczenia PPPoE bedzie mogl tylko komunikowac sie z siecia LAN - nic ponad to.
Wszystko byloby pieknie gdyby nie to, ze defaultowo w Windowsach nie ma PPPoE, co wiecej -
jezeli juz mamy doinstalowane sterowniki - to nie nawiazuja one same polaczenia.
Poza tym samo doinstalowywanie na kazdym komputerze tego protokolu staje sie czasochlonne, co jest dodatkowym minusem tego rozwiazania - jednak - czego nie robi sie dla bezpieczenstwa ? :)
P.S.
Definicje protokolow wykorzystano po czesci z pl.wikipedia.org, reszte napisalem sam z palca, za bledy i literowki oraz niski poziom tekstu serdecznie przepraszam, mile widziane konstruktywne uwagi
Mariusz Kukawski
ququ17@wp.pl
15 Maja 2005
II Sesja Linuksowa
EOF