Előszó
Prologue :
A következő cikkben egy linux bázisú tűzfal telepítését szeretném dokumentálni. A neten nem találtam összefüggő munkát, ami a számomra lényeges funkciók mindegyikét leírta volna, ezért inkább megcsináltam magamnak. Remélem, valakinek segítek ezzel. A cikket elsősorban próbálkozó szellemű embereknek ajánlom linux tapasztalattal. ( linux experience only ! ) A konfigurálás időt fog felemészteni, próbára teszi a türelmet.
Az elkészült rendszer, - mivel egy általános célú operációs rendszerre épül - könnyen kiegészíthető egyéb funkciókkal. Például NAS, email küldés DLNA, stb. Korlátlan lehetőségek tárházát tárja elénk a debian masszív, ~37000 csomagot számláló repositoryja.
Általában a tűzfalakról.
A tűzfal célja nagyon tömören a be- és kimenő hálózati forgalom korlátozása és monitorozása.
Az első "tűzfalat" a 80-as évek végén hozta létre az AT&T. Ez az első generáció a Packet Filter névre hallgat. Minden egyes csomagot vizsgál, attól függetlenül, hogy az egy multipart csomag része vagy sem. A második generáció a 90-es évek elejére tehető. Ezt a generációt a Stateful Firewallnak nevezik. Az osi modell 4-es rétegéig képes üzemelni. Cache-sel minden csomagot és vizsgálja, hogy multipart avagy single csomag.
A mai napra számtalan software-es és hardware-es megoldás létezik. Software-es megoldások között első vonalban említhetjük választott operációs rendszerünk beépített tűzfalát (Windows7 - adv firewall). Egy megfelelően konfigurált kliens oldali tűzfal jelentősen megnehezítheti egy vírus vagy malware dolgát.
Hardware oldalról csak nagyobb neveket említenék, mint Cisco, Juniper. Elég drága eszközök és funkcionalitásuk nagy részét otthoni körülmények között nem használja ki az ember (ASA Cluster, VPN tunnel, stb. ). Egy átlagfelhasználónak bőven elég egy *WRT router, megfelelően konfigurálva, de vannak közöttünk, akiket hajt a cselekvésvágy, nekik szól ez a cikk.
Koncepció
Koncepció:
Esetünkben a tűzfal az ismert és biztonságos(?!) kis helyi hálózatunk és az ismeretlen (veszélyes) internet között helyezkedik el, engedélyez, blokkol csomagokat és minderről különböző csatornákon keresztül értesít minket. Ezen felül szeretnék egy második hálózatot a konfigurálatlan klienseknek, amelyek csak át vannak NAT-olva a netre (tökéletes telefonoknak, cimboráknak, ha átjönnek egy sörre stb. - afféle Guest network).
Egy ábrával talán könnyebb lesz (+ a Guest network későbbiekben dmz demilitarized) :
A kép a shorewall 2 interface firewallról származik.
Keveset módosítottam rajta, hogy illeszkedjen a jelenlegi setupra.
Alapanyagok
Felhasznált hardware
Mint említettem, az előző generációs PC alkatrészeit használtam fel a server építéséhez. Egy-két dolgot vásároltam hozzá, de nem szükségszerű (ház, cf olvasó). Nagyon fontos, hogy legalább 2 - kettő - hálózati csatoló legyen a gépben! Processzorilag egy P3-nak 512 MB RAM-mal bőven elégnek kell lennie! (Otthoni keretek között. Ha 25-en neteztek egyszerre otthon, akkor nem lesz elég :) )( *dsl internet kapcsolattal működhet 1 csatolóval is, de nem lesz a legjobb )
Alaplap : Intel DG31PR
Processzor : Intel E6400
RAM : Kingston 2GB
HD : WD 500 GB
HD : Kingston 300x CF 8GB
NIC : HP 7170 ( dual GBE )
Eddig volt a server.
Ha valaki szeretne wifit, akkor szüksége lesz egy AccessPointra ( AP ) vagy egy routerre, amely képes bridge üzemmódban működni. Ha nem elvárás a wifi, akkor a dmz zónára semmi szükség a továbbiakban és az eth0:1 interface-t sem kell konfigurálni.
Felhasznált software-ek
Az OS stabil , biztonságos. --> LINUX --> Debian 6 ( debian )
A rendszer más linux disztribúciókon is kiépíthető ( „know your weapon”)
Tűzfal --> iptables, Shorewall frontend-el. ( shorewall homepage )
Routing ( sok teendő nincs, a kernelben engedélyezve van a funkció )
DNS szerver --> dnsmasq. ( kicsi, egyszerű ... Nem a legjobb megoldás bár, de lényegesen egyszerűbben konfigurálható, mint a bind. Egy későbbi upgrade alkalmával majd kicserélem bindre )
Dhcp server --> isc-DHCP-server A legelterjedtebb DHCP server. DHCPd homepage
Proxy --> Squid caching proxy. Squid homepage
Kezdjünk telepíteni
Elgondolkodtam egy pillanatra. Leírjam-e az operációs rendszer telepítését?
Nem írom le. Semmi ördöngős nincs benne, aki telepített már linuxot, annak semmi problémát nem okozhat a debian sem. Egy dologra érdemes odafigyelni, a packages selection menüben csak a base systemet kell kiválasztani. Semmi szükség grafikus környezetre, vagy akár a gimpre. Ami kell a base-system mellé, azt majd az apt-get megoldja. Ha valakinek mégis segítség kellene, itt egy link
Folytassuk onnan, hogy kész a debian base install.
Ha valami csoda történt volna és a gép nem vett fel automatikusan IP címet a routerünk DHCP serverétől, akkor bírjuk rá, hogy vegyen.
A telepítés és konfigurálás alatt én végig a vi szerkesztőt használom. Hozzá kell szokni, viszont ha az ember megszokta, elég hatékony! Tetszés szerint lehet használni bármi mást.
cd /etc/network
vi interfaces
auto eth1
iface eth1 inet DHCP
A fenti elemet dobjuk csak bele a file-ba( ki-ki érzése szerint, én eth0 interface-t a belső hálózatomnak szántam, így eth1 lett a majdani internet oldali interface) (ne feledjük ellenőrizni, hogy a hálózati kábel a jelenlegi router és a gép között a gép megfelelő csatolójában van-e )majd :
ifup eth1
Ha reklamál, hogy az interface már konfigurált, akkor :
dhclient -v eth1
A dhclient program ezzel kért nekünk egy IP-t default gatewayt, netmaskot.
Ha minden rendben akkor on-line vagyunk.
apt-get update
apt-get upgrade
Ha csak hibákat kapunk, akkor 2 dolog fordulhatott elő ... ( esetleg a harmadik, ha nem root vagyunk )
1. Nem vagyunk on-line.
2. Hibás az /etc/apt/sources.list file
3. Millió más ok.
Ha a gép nem kapott IP-t vagy rossz a routing, esetleg a tűzfal blokkolja, akkor azt csak az adott helyzet ismeretében lehet megoldani ( Hozzászólások között igyekszem segíteni, ha tudok. ).
Ha viszont csak kattog az apt, hogy helyezze be a .......... lemezt, akkor a sources.list file a ludas.
Kommenteljük ki a tartalmát és biggyesszük a végére a következő két sort:
deb http://ftp.debian.org/debian/ squeeze-updates main
deb http://ftp.debian.org/debian/ squeeze main contrib non-free
majd újra :
apt-get update
apt-get upgrade
Feltételezzük, hogy minden rendben ment.
Van egy naprakész debian base-install. A gép kilát a netre.
Állítsuk be, hogy ha netán újra kellene indítani a gépet, akkor ne kezdjen el egy fsck-t a lemezen, mert nem jó érzés, ha nem jön vissza a gép 3 perc alatt. Ez filerendszertől függ. Példa alapjául nézzünk egy ext3-at.
tune2fs -c 0 /dev/sda1
A következő lépésben konfiguráljuk a hálózatot.
Hálózat
Az hálózati csatolók (a továbbiakban: interface-ek) konfigurálása érdekes történet.
Rálátást és odafigyelést igényel. Telepítés közben ugyanaz az interface lát a netre, amely telepítés után, de - mivel én ssh-n keresztül telepítek - az ssh más interface-en hallgatózik.
Logikusan végiggondolva, az első lehetséges probléma az internetkapcsolatunk.
eth1 interface jelenleg DHCP kliensként üzemel. Ha az internet szolgáltatónk is így ad nekünk IP-t ( pl.: "kábelnet" ), akkor rendben lesz. Ha viszont pppoe ( pl.: ADSL ) kliens a gépünk, akkor ezen majd változtatni kell.
Második probléma a gép. Headless rendszerként fog üzemelni. Minek várni vele, amikor már telepítés alatt is beállítható (biosban Halt on Error --> none).
Szóval jelen esetben telepíteni fogom az open-ssh-server-t, majd beállítom, hogy hallgatózzon az eth1 interface-en. Beállítom a többi interface-em is. Majd a leírás végén, mielőtt kicserélném a routerem, átállítom az ssh server-t, hogy a belső interface-en hallgatózzon tovább.
Az interface-ek beállításait debian alatt a /etc/network/interfaces fájlban végezhetjük el.
auto lo
iface lo inet loopback
auto eth0
iface eth0 inet static
address 192.168.1.1
netmask 255.255.255.0
auto eth0:1
iface eth0:1 inet static
address 192.168.11.1
netmask 255.255.255.0
auto eth1
iface eth1 inet DHCP
eth0-t lesz a belső interface-em. Statikus, IP, netmask, egyértelmű.
ezh0:1 plumb-olt interface. Ez az interface lesz a guset network - dmz.
eth1 az internet felé néző interface (az én szolgáltatóm DHCP-vel szolgál ki).
Ezután állítsuk be a gép nevét, ha a telepítés közben kimaradt.
echo firewall > /etc/hostname
Ezután a "router funkciót" a kernelben.
vi /etc/sysctl.conf
net.ipv4.ip_forward=1
A sor benn lesz a file-ban, csak a # jelet kell törölni a sor elejéről.
Open SSH server
Maga az ssh egy protokol. Jelenleg az open ssh server funkconalitásának igencsak kevés részét használjuk. Egyszerű remote shell lesz a majdani tűzfalunkra. Ha lesz rá érdeklődés ( és időm leírni ), X11 forwarddal lehet wiresharkot futtatni a serveren és valamely kliensünket használni megjelenítőnek.
apt-get install openssh-server
Telepítem dependenciákkal együtt.
A konfigurációs állomány a /etc/ssh/sshd.conf.
Mivel az ssh server befelé fog hallgatózni, nem szántam sok időt a konfigurálására.
vi /etc/ssh/sshd.conf
A konfiguráció lényeges része :
ListenAddress 192.168.1.12
Protocol 2
PermitRootLogin yes
ListenAddress - nálam ezt az IP-t kapta a router-től.
Ha valakinek olyan kedve van, nyugodtan készíthet egy admin csoportos felhasználót és akkor megtilthatja a root belépést ssh-n keresztül. Hangzatos áttenni máshova a portot, de egy portscan viszonylag hamar lefut... ( részemről felesleges nagyon szétkonfigurálni, az ssh befelé hallgatózik )
Ha ez a lépés megvan, akkor be lehet lépni ssh-val. Én itt csináltam egy rebootot és úgy állítottam be, hogy ne álljon meg a POST semmilyen hibára.
Jöhet a tűzfal.
Shorewall 1/3
Tűzfalnak a Shorewall az egyik legegyszerűbb megoldás.
Egy kis wiki idézet :
"Using an analogy understandable to programmers: Shorewall is to iptables, what C is to assembly language."
Szubjektív véleményem átláthatóbbá teszi az iptablest. Szöveges állományokon keresztül manipulálható a tűzfal. Nem csak egy adott dolgot lát az ember a szerkesztéskor. Látom az egész rule setet. Szerintem nagyon jó software! Kiváló támogatással rendelkezik! doc
Telepítése semmi extrát nem igényel. A jelenlegi konfigurációhoz minden funkció be van kapcsolva a debian repositoryjában megtalálható binaryban.
apt-get install shorewall
A shorewall konfigurációja a /etc/shorewall könyvtárban történik bizonyos fájlokon keresztül. Viszont a könyvtár jelenleg üres. Skeleton fájlok találhatóak a /usr/share/doc/shorewall/default-config könyvtárban. Nem lesz az összes itt található file-ra szükségünk. Érdemes tudni, hol találhatóak ezek a fájlok, mivel tartalmaznak példákat és remek leírást.
Mi a következő fájlokat fogjuk használni :
policy - globális szabályok, forgalom irányát figyelve
rules - szabályok kapcsolati szinten
hosts - zónákat határoz meg IP alapján
interfaces - a zónákat interface-ekhez köti
zones - zónákat definiál
masq - NAT / SNAT kapcsolatok beállítására szolgál
shorewall.conf - általános konfiguráció a tűzfalhoz
Kezdjünk hozzá a konfigurációhoz.
A cikk elején a koncepció oldalon kifejtettem, mi is az, amit szeretnénk.
Azt a képet nyugodtan meg lehet nyitni új fülön. A böngésző megbírja, nekünk pedig nagy segítségünkre lesz.
Kezdjük a zóna definíciókkal.
vi zones
fw firewall
net ipv4
dmz ipv4
loc ipv4
A file egyértelmű, zóna neve, típusa. Jelen esetben a saját (biztonságos) hálózatomat neveztem loc-nek. Dmz-nek hívom a vendéghálózatot, főleg mobiltelefonok és cimboráim számára. Net zóna egyértelmű. Fw, ez maga a tűzfal, ez ott áll a net és a többi között.
Következzen az interfaces file, mert a tűzfalnak tudnia kell, melyik interface melyik zóna.
vi interfaces
net eth1 detect DHCP,routefilter,tcpflags,nosmurfs,logmartians
- eth0 192.168.1.255 DHCP
net zónám az eth1 interface. DHCP kliensként üzemel, a többi funkció a wikin megtalálható.
Itt a trükkös rész. Mivel egy interface-en két zónám lesz, ezért nem tudom egyértelműen interface-hez kötni. Erre jó a hosts fájl. ( nem összekeverendő a /etc/hosts-szal )
vi /etc/shorewall/hosts
loc eth0:192.168.1.0/24 -
dmz eth0:192.168.11.0/24 -
!!!nem /etc/hosts!!!
Most már rendesen, IP alapján definiáltak a zónáink. Be kell állítanunk a NAT kapcsolatot.
Előbb lássuk, mi is az a NAT és mire kell? Dióhéjban leírom, miért fontos számunkra. Tegyük fel, a belső hálónkról egy gép el szeretne érni egy gépet (weboldalt, ftp-t, bármit), ami nem a belső hálón van. A tűzfalnak át kell írnia a csomagban a forrást a saját kimenő interface-ére, mivel a külső gép a mi belső gépünket nem éri el - gondoljunk csak bele, hány és hány 192.168.0.2 létezhet . Így a válasz a csomagra sem érhetne célba.
Majd, amint az átírt csomagra válasz érkezik, abban a csomagban a célt átírja a belső gépünk interface-ére és továbbküldi a csomagot, ÉS ... a masq ennek majdnem a fordítottja. NAT-ol minket, de elrejt. Senki nem lát túl a masq szerveren, ha több gépünk van, mindegy, melyikről érkezik a request, a külső eszközök csak a masq server-t látják, ugye, mert Stateful a firewall.
A NAT kapcsolat a masq fájlban állítható.
vi masq
eth1 eth0
Netet "fordít" a belső hálóra . Egyszerű és működik. Ez a file "globális" értelmű. Egész interface-eket érint. Külön szabályokat portokra később adunk meg.
Shorewall 2/3
Következzen a policy.
A policy, mint azt az előző oldalon említettem, főleg irányokkal foglalkozik. Mivel nem szeretnénk semmit, ami a netről származik és nem magunk kértük, ezért dobjuk a hívatlan csomagokat. Egyszerű műveletek, amelyek a csomagok forrásától és céljától függően kerülnek végrehajtásra.
vi /etc/shorewall/policy
###############################################################################
#SOURCE DEST POLICY LOG LIMIT:BURST
# LEVEL
#NEW Config
fw net REJECT debug
fw loc REJECT warning
fw dmz REJECT info
# Policies defining traffic originating from the loc
loc fw REJECT info
loc net REJECT info
loc dmz REJECT info
loc all REJECT info
# Policies defining traffic originating from the dmz
dmz fw REJECT info
dmz net ACCEPT info
dmz loc REJECT info
dmz all REJECT info
# Policies defining traffic originating from the net
net loc DROP info
net dmz DROP info
net all DROP info
# The FOLLOWING POLICY MUST BE LAST
all all REJECT info
#LAST LINE -- DO NOT REMOVE
Ebben a fájlban nem kötelességünk minden "irányt" definiálni. Csak amelyek érdekesek. Többet definiáltam, mint amennyit kellett volna. Az utolsó szabály megoldja a definiálatlan irányokat.
A fájlban a definiciók "ereje" olvasási sorrendben dől el. Ha az utolsó szabály után írnék bármit, az nem kerül feldolgozásra. Hiszen előbb volt az all all REJECT ami illett az irányra.
Nézzük a többi elemét általánosságban. Rengeteg DROP és REJECT. Ez a tűzfal dolga. Egyszerűbb eldobnom mindent és kivételeket megadnom.
A dmz zóna semminemű védelmet/korlátozást nem élvez/tapasztal!!!
Különbség DROP és REJECT között a forrás értesítése (telnet egy REJECT policyval rendelkező irányba azonnali hibaüzenettel jár, DROP irányba várakozás, majd timeout).
Következzenek a kivételek.
Shorewall 3/3
Szabályok, amelyek nem ( feltétlenül ) irányfüggőek.
A rules file szerkeszthető makrók használatával. Én jelenleg csak makrót használtam. A makrók a /usr/local/shorewall könyvtárban találhatóak, macro.* néven. Részemről használatukkal még áttekinthetőbb a rules file.
vi /etc/shorewall/rules
#############################################################################################################
#ACTION SOURCE DEST PROTO DEST SOURCE ORIGINAL RATE USER/
# PORT(S) PORT(S) DEST LIMIT GROUP
#SECTION ESTABLISHED
#SECTION RELATED
SECTION NEW
#don't Drop ping from the NET =D
Ping(ACCEPT) net fw
Ping(ACCEPT) fw net
#Ping on the internal network ( localnet )
Ping(ACCEPT) loc fw
Ping(ACCEPT) fw loc
Ping(ACCEPT) loc loc
#traceroute
Trcrt(ACCEPT) fw net
Trcrt(ACCEPT) loc net
#DNS firewall and loc zones
DNS(ACCEPT) fw net
DNS(ACCEPT) loc fw
DNS(ACCEPT) fw fw
#internal SSH
SSH(ACCEPT) loc fw
SSH(ACCEPT) fw loc
SSH(ACCEPT) loc loc
#DHCP internal
DHCPfwd(ACCEPT) fw loc
DHCPfwd(ACCEPT) net fw
#DHCP for dmz
DHCPfwd(ACCEPT) fw dmz
#Transparent http proxy ports
HTTP(ACCEPT) fw net
HTTPS(ACCEPT) fw net
REDIRECT loc 3128 tcp 80 - !192.168.1.0/24
ACCEPT loc fw tcp 3128
HTTPS(ACCEPT) loc loc
HTTP(ACCEPT) loc loc
#LAST LINE -- ADD YOUR ENTRIES BEFORE THIS ONE -- DO NOT REMOVE
Hosszú a config. Azért ekkora, mert nem szabad a csomagáramlás a belső hálózaton. Ha azt szabaddá tenném, lényegesen rövidebb lenne. Szeretem, ha nem szabad, így látom, ha valamelyik gép "rendetlenkedik".
Ezzel a rulesettel nem működik sok minden. Kapunk IP-címet a DHCP serverünktől. Megy a böngészés és a traceroute. Tudunk ssh-zni összevissza a hálózaton és megy a ping.
Minimalista (paranoiás)
Említek egy-két példát egy-két szolgáltatásra, de a makrók között sokkal többet találni, szabadon pedig bármi definiálható.
tftp a helyi hálón :
TFTP(ACCEPT) loc loc
ftp elérés a "net"-en
FTP(ACCEPT) loc net
teamviewer cimbora gépére
ACCEPT loc net tcp 5938
samba server otthon
SMB(ACCEPT) loc loc
HP Laserjet otthon
Jetdirect(ACCEPT) loc loc
tegyük fel, van egy NAS-unk otthon, az IP-je 192.168.1.2 .
Minden éjjel ellenőrzi a raid konzisztenciát és elküldi email-ben, tegyük fel továbbá, hogy nincs saját email szerverünk és pont a Google-ét használjuk :
SMTPS(ACCEPT) loc:192.168.1.2 net:173.194.70.108,173.194.70.109
SMTPS(ACCEPT) net:173.194.70.108,173.194.70.109 loc:192.168.1.2
Ha valaki játszik otthon és épp Steamet használ, annak is egy kis segítség :
ACCEPT loc net tcp 27010:27040
ACCEPT loc net udp 27010:27040
Szenteljünk egy kis figyelmet a Transparent http proxy ports részlegre. Ott egy REDIRECT, nem makró. Egész egyszerűen a loc zóna tcp/80-as portjáról érkező csomagokat átdobja a 3128-as portra, kivéve ha a csomagok célállomása a saját hálómon van. A 3128-as porton fog hallgatózik a proxy. http módban áttetsző lesz. :)
A többi szolgáltatás bizony odafigyelést igényel. Ki kell deríteni a használt portokat, engedélyezni őket.
A logfile-ból minden kiderül. Ha nem vesszük észre, a Google is segít.
Kicsit szebben néz ki a dolog, ha a logjait külön facilityba dobjuk.
Sajnos erre nem találtam megoldást. Viszont az rsyslog kiválóan képes válogatni az üzenetekben !
Szóval hozzunk létre egy file az /etc/rsyslog.d könyvtárban 10-shorewall.conf néven.
A fájlba a következő bejegyzés kell:
:msg, startswith, "Shorewall:" -/var/log/shorewall.log
& ~
:msg, regex, "^\[ *[0-9]*\.[0-9]*\] Shorewall:" -/var/log/shorewall.log
& ~
ezután touch /var/log/shorewall.log
Végül, hogy egy indításra el is induljon, szerkesztenünk kell a shorewall.conf fájlt is.
Ezt a fájlt érdemes másolni a skeletonok közül.
cp /usr/share/doc/shorewall/default-config/shorewall.conf /etc/shorewall/
Majd keressük meg a következő sort :
startup=0
Írjuk át a 0-t 1-re. És el is indul, ha indítjuk. Még ne indítsuk, felesleges.
DNS
Vegyük sorra, mit is tettünk eddig.
Van egy friss debian installunk. Hiányzik belőle minden felesleges dolog. Beállítottuk a megfelelő hálózati interface-eket. Telepítettünk egy ssh szervert és egy tűzfalat. Konfiguráltuk mind a kettőt, ez elrendezte a routingot is.
Ez szép és jó, de ha most kicserélnénk a routerre, még nem lenne az igazi. Szükségünk lesz a DHCP egyszerűségére, luxusára és jó lenne a name resolvation is, a proxyról nem is beszélve.
Long way to go ...
DNS
Domain Name System.
( Nagyon nagyon nagyon )egyszerűre fogva. Ez mondja meg a böngészőnknek, hogy amikor beírjuk, hogy prohardver.hu akkor ő a 92.61.114.124-es IP-t próbálja.
A DNS rendszert bővebben és nálam sokkal jobban kifejtette bambano felhasználó. Itt egy link.
Nem egy hatalmas A vagy B osztályú hálózatot szeretnénk kiszolgálni, szóval részemről egy lightweight DNS szerver bőven elég a célnak.
apt-get install dnsmasq
A konfigurációs állománya a /etc/dnsmasq.conf.
local=/localnet/
interface=eth0
expand-hosts
domain=localnet
log-queries
local= ...
a domainnév, amit a DHCPD-nek is megadunk.
Interface=
az interface, amin hallgatózik a kérésekért.
expand-hosts
Ha a hostban van mondjuk a „printer” bejegyzés, akkor ez kiterjeszti printer.localnet-re
domain=
szintúgy domainnév, kell mind a kettő!
log-queries
Azért, hogy lássuk, mit csinál. Ha minden megy, ez a sor kivehető. A log : /var/log/daemon
Ennyi, megy is.
DHCP
DHCPD !
apt-get install isc-DHCP-server
vi /etc/DHCP/DHCPd.conf
authoritatvie;
ddns-update-style interim;
default-lease-time 86400;
max-lease-time 172800;
set vendor-string = option vendor-class-identifier;
log-facility local7;
option routers 192.168.1.1;
option broadcast-address 192.168.1.255;
option subnet-mask 255.255.255.0;
option domain-name "localnet";
option domain-name-servers 192.168.1.1;
shared-network localnet {
subnet 192.168.11.0 netmask 255.255.255.0 {
pool {
range 192.168.11.100 192.168.11.140;
option routers 192.168.11.1;
option domain-name-servers 8.8.8.8;
allow unknown-clients;
}
}
subnet 192.168.1.0 netmask 255.255.255.0 {
pool {
range 192.168.1.100 192.168.1.140;
deny unknown-clients;
host somehost1 {
hardware ethernet 00:00:00:00:00:00;
}
}
}
}
group {
host somehost2 {
hardware ethernet 00:00:00:00:00:00;
fixed-address 192.168.1.6;
}
A DHCP server önmagában is egy külön mise lehetne. Ezt igyekeztem egy copy-paste konfigurációnak megcsinálni. A módosítás, ami kell rajta, az a kliensek MAC addresse.
Fontosak a ; és nyitó { illetve bezáró } jelek.
Minden szekciót ki kell nyitni és be is kell zárni!
Plusz infóként. Ha a végén a Group szekcióba írunk hostot, az ne legyen a DHCP dinamikus tartományában, tehát kerüljük a range-ben foglalt címeket. Ez arra van, hogy azon kívül is meg tudjunk adni dolgokat, amelyek statikusak. Nekem például a nyomtatóm van itt. Nem szeretném minden alkalommal újra telepíteni, ha más IP-t kap. A Poolon belül lévő host szekcióban pedig nem kell megadnunk elvárt IP-t, mivel a pool dinamikus. Oda csak be kell írni a hostnevet és a MAC addresst.
A rendszer 2 alhálóval üzemel.( loc és dmz ). Loc hálóval semmi gond, a saját dnsmasq megoldja a névfeloldást. Viszont a DMZ-t nem szeretném, hogy hozzáférjen a vashoz. Átadom neki a Google public name servert és kész.
Ha látni szeretnénk a DHCP serverünk logját akkor az /etc/rsyslog.conf file-ban létre kell hoznunk a következő szabályt:
local7.* /var/log/DHCPd.log
Ez azt eredményezi, hogy a local7-es facility üzenetei a /var/log/DHCPd.log-ba lesznek irányítva. Alapból a local7-en nincs semmi.
Következzen a proxy.
Squid cache
A Squid caching proxy az egyik ( ha nem a ) legjobb proxy jelenleg.
Proxy, na igen. Mindenki hallott már róla.
Nagyon az alapkonfigurációt vesszük. Nem lesz tartalomszűrés, sem blokkolt oldalak. Authentication sem.
Egy egyszerű web cache-t hozunk létre.
( transzparens http móddal )
apt-get install squid3.
Lesz függősége bőségesen. Mi csak telepítsük.
Ezután jöhet a konfiguráció.
acl manager proto cache_object
acl localhost src 192.168.1.0/24
acl localhost src 127.0.0.1/32 ::1
acl to_localhost dst 127.0.0.0/8 0.0.0.0/32 ::1
acl my_network src 192.168.1.0/24 # RFC1918 possible internal network
acl SSL_ports port 443
acl Safe_ports port 80 # http
acl Safe_ports port 21 # ftp
acl Safe_ports port 443 # https
acl Safe_ports port 70 # gopher
acl Safe_ports port 210 # wais
acl Safe_ports port 1025-65535 # unregistered ports
acl Safe_ports port 280 # http-mgmt
acl Safe_ports port 488 # gss-http
acl Safe_ports port 591 # filemaker
acl Safe_ports port 777 # multiling http
acl CONNECT method CONNECT
acl NO-CACHE-SITES dstdomain youtube.com
no_cache deny NO-CACHE-SITES
http_access allow manager localhost
http_access deny manager
http_access deny !Safe_ports
http_access deny CONNECT !SSL_ports
http_access allow my_network
http_access allow localhost
http_access deny all
http_port 192.168.100.1:3128 transparent
hierarchy_stoplist cgi-bin ?
cache_mem 512 MB
maximum_object_size_in_memory 1024 KB
cache_dir ufs /media/sdb/squid3 10000 16 256
maximum_object_size 250 MB
cache_swap_low 90
cache_swap_high 93
access_log /var/log/squid3/access.log squid
cache_store_log /var/log/squid3/store.log
pid_filename /var/run/squid3.pid
coredump_dir /webcache/squid3
refresh_pattern ^ftp: 1440 20% 10080
refresh_pattern ^gopher: 1440 0% 1440
refresh_pattern -i (/cgi-bin/|\?) 0 0% 0
refresh_pattern . 0 20% 4320
positive_dns_ttl 6 hours
negative_dns_ttl 1 minutes
dns_timeout 32 seconds
dns_nameservers 1.1.1.1
hosts_file /etc/hosts
memory_pools on
memory_pools_limit 500 MB
copy paste ---> működik ! (amennyiben létezik a /webcache/squid3 könyvtár és van rajta 10 GB szabad hely.)
Pár dolgot kiragadnék a konfigból.
pid_filename /var/run/squid3.pid van alapértelmezése, de nézzük meg, hogy tmpfs-en van-e!
acl NO-CACHE-SITES dstdomain youtube.com Létrehozok egy AccessControlList-et melynek neve NO-CACHE-SITES majd meghatározom hogy a dstdomain youtube.com
no_cache deny NO-CACHE-SITES - kizárom a cache-ből az imént létrehozott acl-t.
acl my_network src 192.168.1.0/24 # RFC1918 possible internal network
http_access allow my_network
dns_nameservers 1.1.1.1 Elvileg erre akkor van szükség, ha mást szeretnék használni, mint ami a /etc/resolv.conf ban van, de meg kell adni ugyanazt a nameservert, ami a /etc/resolv.conf-ban van. Nem, nem működik... külön be kell írni.
A böngészőnk a redirect miatt a tűzfalban nem fog igényelni proxy beállítást http kérésekhez, de a https-t be kell állítanunk!
Miért nincs transparent https ?! Mert csak. A Squid képes rá, de nem! Könnyű rosszra használni. Onnantól már hiába https. Gyakorlatilag egy "man in the middle". Senki nem szeretne a rossz oldalán állni.
Ha ez megvan, akkor elvileg mehetne egy kikapcsolás, átkábelezés, bekapcsolás.
DE...
Teszt/Hibakeresés
Nem fog menni. Túl sok konfiguráció. Inkább teszteljünk.
A shorewall konfigurációját a következő paranccsal ellenőrizhetjük :
shorewall check
A shorewall, hála az égnek, külön helyre dobja az init logot és a futásit.
A shorewall indulásának a logfile-ja a /var/log alatt található, neve shorewall-init.log
A futási logokat a messagesbe dobálja. ( az rsyslog.conf-ban átállítottuk, hogy külön a shorewall üzenetei megjelenjenek a /var/log/shorewall.log -ban is)
A DHCPD logfile-ját magunk állítottuk be a /var/log/DHCPd.log –ra.
A DHCPd server konfigját a következő képp ellenőrizhetjük :
DHCPD -t /etc/DHCP/DHCPd.conf
A parancs után a DHCP server nem fut! Csak a config file-t ellenőrzi.
Indítani, a /etc/init.d/isc-DHCP-server start paranccsal tudjuk.
Érdemes rákötni egy laptopot vagy valamit, hogy kap-e címet stb.
Ha úgy érezzük, minden rendben, akkor még egy kis konfiguráció.
Kedvenc gépünk MAC addressét ne felejtsük el rögzíteni a DHCPd.conf-ban, ha a trusted hálózaton szeretnénk helyet foglalni.
Át kell írnunk az openssh server ListenAdressét a másik, statikus IP-vel rendelkező IP-re.
Ha ez megvan, akkor mehet a csere !
Ha nem működne a böngészés, egy kis segítség :
Squid teszt :
squidclient -h 192.168.1.1 -p 3128 http://www.prohardver.hu/
Ezzel a paranccsal egy célszerver http adatait kérdezhetjük le a proxy-n keresztül.
squidclient -h 192.168.1.1 -p 3128 mgr:info
Ezzel pedig a saját cache manager-ünket ellenőrizhetjük.
Látni fogjuk többek között a névfeloldás idejét ( egy példa a saját proxymból ).
Median Service Times (seconds) 5 min 60 min:
HTTP Requests (All): 0.00000 0.00000
Cache Misses: 0.12106 0.07409
Cache Hits: 0.00000 0.00000
Near Hits: 0.00000 0.05046
Not-Modified Replies: 0.00000 0.00000
DNS Lookups: 0.00000 0.02562
ICP Queries: 0.00000 0.00000
Ha nagyon magas, akkor érdemes kipróbálni, hogy shellből érzésre gyors-e a névfeloldás, ha nincs névfeloldás, akkor mehet egy ping is.
nsllookup prohardver.hu
ping 92.61.114.124
Ha nem jön vissza szinte azonnal a válasz, akkor nem a squid nem tud nevet feloldani, hanem a /etc/resolv.conf lesz a ludas. Vagy a tűzfal blokkolja a dns lookupot.
Ez csak egy példa volt a lehetséges hibák közül.
Zárógondolat
Ha valami nagyon nem megy :
1.:
A tűzfalban, ha következő módosítást végrehajtjuk, akkor a gépünk ki fog látni a netre, de a net nem lát vissza a gépre, illetve szabad lesz a csomagáramlás a helyi hálón.
vi /etc/shorewall/policy
cseréljük a következő sort :
loc net REJECT info
a következőre :
loc net ACCEPT info
illetve a következőt :
loc loc REJECT info
a következőre :
loc loc ACCEPT info
majd : /etc/init.d/shorewall restart
2.:
A DHCP server-t újra kell indítani, ha módosítottuk a konfigurációját.
Remélem, minden működik mindenkinek.
Használjátok egészséggel!
Nálam sokkal képzettebb és rutinosabb emberek is vannak a PH! fórumokon, de én is igyekszem segíteni, ha problémás lenne a helyzet.
