|
 |
Linuxskolen del 6 (LINUXmagasinet 5/2002)
En sikrere server
Oppsett av IP-tables-basert firewall, Squid proxyserver og squidGuard for filtrering av websider.
Som jeg lovte i forrige artikkel, “Oppsett av din egen intranett server”, skal jeg denne gangen vise litt av hva du kan foreta deg for å sikre nettet ditt mot både de som er utenfor og innenfor husets fire vegger. “Mot de som er innenfor også?” spør du kanskje? - Ja, det er alvorlig ment ! Du behøver kanskje ikke så mye beskyttelse mot dem, men har du unger i huset som benytter internett på egen hånd oppdager du nok snart at de faktisk har god bruk for beskyttelse mot seg selv og mye av den delen av internett vi helst vil holde ungene borte fra. Mer om det litt senere.
Når du nå sitter der med den nye serveren ville det jo vært flott å få delt den med andre enn bare de på innsiden av huset. For å forenkle den videre gangen i artikkelen noe, forutsetter jeg at du benytter Red Hat 7.3 og har tilgang til en eller annen form for fast tilknytning til internett. Dette kan være via kabel, ADSL eller trådløst bredbånd eller lignende. For å kunne benytte dette må du sette inn et ekstra nettverkskort i intranett-serveren din, eller enda bedre - i en separat maskin som kan utføre jobben som gateway. Dette kan gjerne være en gammel 486/Pentium dersom du skulle ha en slik stående. Grunnen til at dette bør være en annen maskin enn serveren din er enkel: Å begrense skadene i tilfelle noen bryter seg inn på systemet. Det er lettere å sette opp en gateway på ny, enn å reinstallere en hel server !
Denne ekstra maskinen forer du med Linux uten å legge inn X Window. X behøves ikke på en slik gateway, og på denne måten sparer vi både diskplass og RAM. Imidlertid passer du på å installere IP-tables (iptables-1.2.5-3). Du putter i 2 nettverkskort og setter opp det ene som eth0 med den interne IP-adressen (eks. 192.168.1.254) og det andre som eth1 med den eksterne IP'en du fikk ifm fasttilknytningen din. Konfigurasjonen kan du gjerne gjøre grafisk ved hjelp av 'linuxconf'. Da kan du stå igjen med følgende ved å kjøre kommandoen 'ifconfig':
[kolbjorn@canopus kolbjorn]$ /sbin/ifconfig
eth0 Link encap:Ethernet HWaddr 00:60:97:4A:5D:BD
inet addr:192.168.1.2 Bcast:192.168.1.255 Mask:255.255.255.0
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:3339076 errors:223 dropped:0 overruns:418 frame:223
TX packets:3328573 errors:0 dropped:0 overruns:0 carrier:50
collisions:7506
RX bytes:796271623 (759.3 Mb) TX bytes:1341902862 (1279.7 Mb)
eth1 Link encap:Ethernet HWaddr 00:02:2D:0D:A2:40
inet addr:213.151.142.253 Bcast:213.151.142.255 Mask:255.255.255.0
UP BROADCAST NOTRAILERS RUNNING MTU:1500 Metric:1
RX packets:7984177 errors:0 dropped:0 overruns:0 frame:0
TX packets:3218876 errors:0 dropped:0 overruns:0 carrier:0
collisions:0
RX bytes:2070712664 (1974.7 Mb) TX bytes:730717924 (696.8 Mb)
lo Link encap:Local Loopback
inet addr:127.0.0.1 Mask:255.0.0.0
UP LOOPBACK RUNNING MTU:16436 Metric:1
RX packets:493 errors:0 dropped:0 overruns:0 frame:0
TX packets:493 errors:0 dropped:0 overruns:0 carrier:0
collisions:0
RX bytes:955298 (932.9 Kb) TX bytes:955298 (932.9 Kb)
For å kunne nå internett fra de andre maskinene i nettet ditt må du sette opp IP-Masquerade på din nye gateway. Dette betyr ikke annet enn at gatewayen settes i stand til å maskere disse andre PC-ene ved at den utad mot internett fremviser kun EN IP-adresse for alle maskinene. Dette er i grove trekk det samme som NAT (Network Address Translation) som finnes i mange kommersielle rutere/gatewayer ute på internett. Denne nettverksfunksjonaliteten er tilstede i en standard Red Hat-installasjon, men legger du inn en ny kjerne i ettertid må du selv kompilere inn IP-Masq. Sjekk i så fall nødvendige HOWTO's (http://ldp.linux.no/HOWTO/IP-Masquerade-HOWTO/index.html)på forhånd.
I tillegg til IP-Maqsq. må maskinen også benytte IP-Forwarding til å fremsende informasjonspakker til de respektive maskinene i intern-nettet ditt. Det du står igjen med etter å ha satt opp en slik maskerende gateway er:
En “usynlig” tilgang til internett for en hel gruppe maskiner. Bare IP-adressen til gateway'en er synlig utad. Ved at man samtidig setter opp brannmuren på denne maskinen innføres i tillegg den nødvendige sikkerheten mot inntrengning. Alt på EN maskin. Det finnes et utall brannmurer og måter disse kan settes opp på. I mitt tilfelle har jeg valgt IKKE å benytte den som følger med RedHat. Årsaken til dette er enkel:
Jeg er ikke noen kløpper i iptables, noe som er en nødvendighet for å sette opp en så god brannmur som mulig. Noen av dere er sikkert nettopp slike kløppere og dere får bare ha meg unnskyldt.
For å sikre meg så godt som mulig har jeg valgt å benytte et ferdig, og godt testet firewall script som er laget av MonMotha. Monmothas Firewall er et bash-script som, etter at det er satt opp for ditt nettverk, tar seg av all nødvendig funksjonalitet i forbindelse med en slik gateway, samt at den lar deg innføre “port forwarding” mellom brannmur/gateway og de andre maskinene/serverene i nettet bak denne. Scriptet er kun avhengig av at du kjører en 2.4-kjerne og at iptables er installert og støttet. Med RedHat 7.3 har du en slik situasjon, og ingen forandringer skulle være nødvendig i så henseende. På denne måten vil eventuelle forespørsler til min webserver fra internett foregå slik:
http fra internett ) arctic-linux.tnett.no fw/gw (213.151.142.253) port 80 ) videresendes til intern maskert webserver (192.168.1.1) port 80
Det samme skjer i forbindelse med secure shell-forespørsler hos meg. ssh mot arctic-linux.tnett.no kommer først inn til min fw/gw på 213.151.142.253 før den rutes videre mot intern ssh-server.
Det eneste du MÅ gjøre selv er:
Hente siste versjon av scriptet fra internett
http://monmotha.mplug.org/firewall/index.php
Konfigurere dette iht tipsene foran hvert felt.
Du kan se et eksempel på et slikt opp sett i punkt 4.
Stoppe automatisk oppstart av RedHat's brannmur:
'/sbin/chkconfig --level 0123456 iptables off'
Laste inn nødvendige IP-tables moduler i kjernen.
Dette gjør du med kommandoen '/sbin/modprobe iptable_nat'
og går dette bra vil '/sbin/lsmod' vise
ipt_MASQUERADE 1664 1 (autoclean)
ipt_LOG 3856 15 (autoclean)
iptable_mangle 2160 0 (autoclean) (unused)
ipt_REJECT 3392 7 (autoclean)
ipt_limit 1360 17 (autoclean)
ipt_state 1024 4 (autoclean)
iptable_filter 2128 0 (autoclean) (unused)
iptable_nat 16528 0 [ipt_MASQUERADE]
ip_conntrack 15824 2 [ipt_MASQUERADE ipt_state iptable_nat]
ip_tables 10944 10 [ipt_MASQUERADE ipt_LOG iptable_mangle ipt_REJECT ipt_limit ipt_state iptable_filter iptable_nat]
Eksempel oppsett:
IPTABLES="/sbin/iptables"
TCP_ALLOW="21 22 25 80 110 119”
UDP_ALLOW=""
INET_IFACE="eth1”
LAN_IFACE="eth0"
INTERNAL_LAN="192.168.1.0/24"
MASQ_LAN="192.168.1.0/24"
SNAT_LAN="192.168.1.0:din.eksterne.ip.adresse"
DROP="TREJECT"
DENY_ALL=""
DENY_HOSTWISE_TCP=""
PORT=""
DENY_HOSTWISE_UDP=""
PORT=""
BLACKHOLE=""
BLACKHOLE_DROP="DROP"
ALLOW_HOSTWISE_TCP=""
ALLOW_HOSTWISE_UDP=""
TCP_FW="21:21)192.168.1.1 22:22)192.168.1.1 25:25)192.168.1.1 80:80)192.168.1.1 110:110)192.168.1.1 119:119)192.168.1.1"
UDP_FW=""
MANGLE_TOS_OPTIMIZE="FALSE"
DHCP_SERVER="FALSE"
ENABLE="Y"
LOG_FLOOD="2/s" # Limit on logging (for LTREJECT, LREJECT and LDROP, the packet will always take the policy regardless of logging)
SYN_FLOOD="20/s"
PING_FLOOD="1/s"
ALLOW_OUT_TCP=""
PROXY=""
MAC_MASQ=""
MAC_SNAT=""
TTL_SAFE=""
USE_SYNCOOKIES="FALSE"
RP_FILTER="TRUE"
ACCEPT_SOURCE_ROUTE="FALSE"
BAD_ICMP="5 9 10 15 16 17 18"
SUPER_EXEMPT=""
BRAINDEAD_ISP="FALSE"
DMZ_IFACE=""
Resten av scriptet trenger ikke noe konfigurering, og er derfor utelatt, samt at jeg har utelatt informasjonen i forbindelse med hvert enkelt punkt for å gjøre listen kortere. Det jeg har tillatt i scriptet over er:
21: ftp
22: ssh (secure shell innlogging istedet for telnet)
80: http (web)
25: smtp (mail sending)
110: pop3 (mail mottak)
119: nntp (news)
Starte scriptet
Resultatet av denne konfigurasjonen er:
[root@canopus rc.d]# ./rc.firewall-2.3.8-pre6
Loading iptables firewall:
Checking configuration...passed
Checking IP Forwarding...enabled.
Checking IP SynCookies...disabled.
Checking Route Verification...activated:eth1 activated:eth0
Refusing SSR Packets via SysCtl...activated:eth1 activated:eth0
Flush: INPUT OUTPUT1 FORWARD PREROUTING1 OUTPUT2 POSTROUTING PREROUTING2 OUTPUT3
Creating chains: INETIN INETOUT DMZIN DMZOUT TCPACCEPT UDPACCEPT LDROP LREJECT TREJECT LTR
EJECT
Default Policies: INPUT:DROP OUTPUT:ACCEPT FORWARD:DROP
Setting up drop chains chains: LDROP LREJECT TREJECT LTREJECT
Setting up per-proto ACCEPT: TCPACCEPT UDPACCEPT
TREJECTing invalid packets...done
Setting up INET chains: INETIN INETOUT
Local Traffic Rules: 192.168.1.0/24:ACCEPT loopback:ACCEPT
Setting up masquerading: 192.168.1.0/24:MASQUERADE
Setting up static NAT: 192.168.1.0:SNAT
TCP Port Forwards: 21:21)192.168.1.1 22:22)192.168.1.1 25:25)192.168.1.1 80:80)192.168.1.1
110:110)192.168.1.1 119:119)192.168.1.1
Dropping ICMP messages specified in BAD_ICMP...5 9 10 15 16 17 18
Flood limiting: ICMP-PING
Allowing the rest of the ICMP messages in...done
TCP Input Allow: 21 22 25 80 110 119
UDP Input Allow:
Allowing established outbound connections back in...done
Allowing related inbound connections...done
Setting up INET policies: INETIN:TREJECT INETOUT:ACCEPT
Done loading the firewall!
Nå er det verste gjort !
Du kan nå konsentrere deg litt om jobben med å “beskytte” dine interne brukere mot seg selv, samt gjøre et forsøk på å begrense nettverkstrafikken din noe. Et av de enkleste knepene her er å installere en proxy-server. En proxy-server står i mellom brukerne og alle web-servere og/eller ftp-servere de måtte surfe forbi i løpet av sin tid foran PC'en. Det den gjør er å cache (mellomlagre) all informasjonen som du har bestemt skal gå via proxy slik at når den samme informasjonen (eksempel: websiden) kalles opp neste gang hentes den fra din lokale proxy istedet for å taes fra internett. Dette kan også gjelde nedlastning av filer via web-klienter.
Squid Cache
En slik proxy-server er Squid cache. I tillegg til å mellomlagre websider o.l. sørger også Squid for samme funksjonalitet ifm DNS oppslag (navnetjener), SSL (secure socket layer) og negativ lagring av feilslåtte kall på internett. Squid installeres enten fra kildekode (http://www.squid-cache.org/Versions/v2/2.5/squid-2.5.STABLE1.tar.gz) eller om du fortsatt benytter Red Hat 7.3 (wget sunsite.uio.no/pub/Linux/RedHat/redhat/7.3/en/os/i386/RedHat/RPMS/squid-2.4.STABLE6-1.7.2.i386.rpm). Konfigurasjonen kan bli både enkel og avansert, alt etter dine ønsker og behov, men mitt råd er: Start med det enkle og få det til å fungere. Etter dette tar du til med den litt mer avanserte tilnærmingen. Faktum er at Squids default oppsett fungerer ypperlig for de fleste med små justeringer dersom den kjøres på samme maskin som webserver og dns. Jeg gjør det på denne måten, og av alle feltene i squid.conf har jeg KUN måttet forandre disse for å oppnå basis funksjonalitet:
# ACCESS CONTROLS
# -----------------------------------------------------------------------------
# TAG: acl
# Defining an Access List
acl canopus src 192.168.1.2/255.255.255.0
acl antares src 192.168.1.3/255.255.255.0
acl capella src 192.168.1.4/255.255.255.0
acl vega src 192.168.1.1/255.255.255.0
#
# INSERT YOUR OWN RULE(S) HERE TO ALLOW ACCESS FROM YOUR CLIENTS
#
http_access allow canopus
http_access allow capella
http_access allow antares
http_access deny all
# ADMINISTRATIVE PARAMETERS
# -----------------------------------------------------------------------------
# TAG: cache_mgr
# Email-address of local cache manager who will receive
# mail if the cache dies. The default is "webmaster."
#
cache_mgr
kolbjorn@arctic-linux.tnett.no
# TAG: visible_hostname
# If you want to present a special hostname in error messages, etc,
# then define this. Otherwise, the return value of gethostname()
# will be used. If you have multiple caches in a cluster and
# get errors about IP-forwarding you must set them to have individual
# names with this setting.
#
visible_hostname www-cache.arctic-linux.tnett.no
Med disse forandringene har jeg tilpasset Squid til mitt nettverk og fortalt hvilke maskiner som får benytte den. Squid inneholder en mengde opsjoner, så for å få en oversikt over resten, sjekk:
http://squid.visolve.com/squid24s1/contents.htm
Når du er fornøyd med oppsettet er det bare en ting som gjenstår; Å fortelle Galeon, Netscape, Mozilla, Opera og de andre browserne som dine brukere benytter at de heretter skal aksessere internett via Squid. Se mitt eksempel for Galeon på bildet. I Netscape går du inn på Edit ) Prefrences ) Advanced ) Proxies og setter inn de samme parametrene som vist for Galeon.
For å kontrollere at Squid fungerer kan du benytte grafiske verktøy som Cache Manager (http://www.squid-cache.org/Doc/FAQ/FAQ-9.html#cachemgr-section), eller du kan sjekke logg-filen direkte.
squidGuard
squidGuard er en meget nyttig sak å ha installert i forbindelse med Squid Cache. squidGuard er et kombinert filter, redirector og access controller plugin for Squid. Dvs at den for bestemte URL'er, brukernavn eller ip-adresser viderekobler disse til “godkjente” websider o.l. På denne måten gies du en unik mulighet til å bestemme hva enkelte (eller alle) i nettet ditt skal ha anledning til å surfe over. Spesielt for de små web-brukerene er dette gode nyheter. squidGuard benytter seg av såkalte Blacklists (http://www.squidGuard.org/blacklist/) som er tekstfiler inneholdende alle tenkelige ip-adresser og URLer for porno, vold og annen dritt som man ikke ønsker inn i huset. Etter at squidGuard er startet vil en forespørsel til slike sider resultere i at man får opp en side som forteller at dette ikke er tillatt, og at man heller bør fokusere på andre websider. Se bildet ! Dette systemet fungerer ypperlig og er virkelig til å stole på, men det betinger at man oppdaterer sine blacklists nå og da for å holde tritt med utviklingen i nye websteder med porno etc.
Installasjonen er forholdsvis enkel, men for å gi deg en hjelpende hånd skal jeg gi deg min:
Laste ned squidGuard:
Dette kan du enten gjøre ved å hente rpm'en for RH 7.2 (http://arachna.uptime.at/rpms/pages/RH7.2-Enigma//squidGuard-1.2.0-3.i386.html), eller du kan gjøre det jeg ville gjort, nemlig å hente kildekoden (http://ftp.teledanmark.no/pub/www/proxy/squidGuard/squidGuard-1.2.0.tar.gz) og kompilere den selv.
Konfigurere squidGuard.conf:
Her er mitt oppsett som er noe strengt.
#
# Sample configuration for squidGuard at Arctic Linux
# (for further configuration options see the
# documentation and http://www.squidGuard.org/)
#
dbhome /var/db/squidGuard
logdir /var/log
#
# DESTINATION CLASSES
#
dest ads {
domainlist ads/domains
urllist ads/urls
}
dest aggressive {
domainlist aggressive/domains
urllist aggressive/urls
}
dest audio-video {
domainlist audio-video/domains
urllist audio-video/urls
}
dest drugs {
domainlist drugs/domains
urllist drugs/urls
}
dest gambling {
domainlist gambling/domains
urllist gambling/urls
}
dest hacking {
domainlist hacking/domains
urllist hacking/urls
}
dest mail {
domainlist mail/domains
}
dest porn {
domainlist porn/domains
urllist porn/urls
expressionlist porn/expressions
}
dest proxy {
domainlist proxy/domains
urllist proxy/urls
}
dest violence {
domainlist violence/domains
urllist violence/urls
expressionlist violence/expressions
}
dest warez {
domainlist warez/domains
urllist warez/urls
}
acl {
default {
pass !ads !aggressive !audio-video !drugs !gambling !hacking !mail !porn !proxy !violence !warez !in-addr all none
redirect http://www.arctic-linux.tnett.no/not-allowed.html
}
Med denne konfigurasjonen oppnår du en meget god sikkerhet i squidGuard. Jeg føler meg i allefall trygg når mine unger surfer !
Websiden redirect benytter i slutten av min squidGuard.conf er ikke inkludert i squidGuard og må opprettes av deg selv på din egen webserver. Egentlig er det jo nok å sette opp en eller annen HYGGELIG webside (http://www.disney.no/DonaldDuck/) som redirect, men det er vel OK å si ifra til sine håpefulle at “Hei ! Vi passer på !!”.
Nå må du sørge for at du har installert siste versjon av blacklists. Disse finner du på ftp://ftp.teledanmark.no/pub/www/proxy/squidGuard/contrib/blacklists.tar.gz, og de skal vanligvis installeres i /var/db/squidGuard. En 'ls' i denne katalogen på min server gir meg:
vega# ls -l /var/db/squidGuard/
total 756
-rw-r----- 1 root nogroup 508 Jun 19 2002 README
dr-xr-x--- 2 nobody nogroup 512 Jun 19 2002 ads
dr-xr-x--- 2 nobody nogroup 512 Jun 19 2002 aggressive
dr-xr-x--- 2 nobody nogroup 512 Jun 19 2002 audio-video
-rw-r--r-- 1 root nogroup 752166 Jun 19 2002 blacklists.tar.gz
dr-xr-x--- 2 nobody nogroup 512 Jun 19 2002 drugs
dr-xr-x--- 2 nobody nogroup 512 Jun 19 2002 gambling
dr-xr-x--- 2 nobody nogroup 512 Jun 19 2002 hacking
dr-xr-x--- 2 nobody nogroup 512 Jun 19 2002 mail
dr-xr-x--- 2 nobody nogroup 512 Jun 19 2002 porn
dr-xr-x--- 2 nobody nogroup 512 Jun 19 2002 proxy
dr-xr-x--- 2 nobody nogroup 512 Jun 19 2002 violence
dr-xr-x--- 2 nobody nogroup 512 Jun 19 2002 warez
Hmmm... jeg bør nok oppdatere litt. NÅ !!
vega# ls -l /var/db/squidGuard/
total 11
drwxr-x--- 2 root nogroup 1024 Oct 6 12:20 ads
drwxr-x--- 2 root nogroup 512 Oct 6 12:20 aggressive
drwxr-x--- 2 root nogroup 1024 Oct 6 12:20 audio-video
drwxr-x--- 2 root nogroup 1024 Oct 6 12:20 drugs
drwxr-x--- 2 root nogroup 512 Oct 6 12:21 gambling
drwxr-x--- 2 root nogroup 512 Oct 6 12:21 hacking
drwxr-x--- 2 root nogroup 512 Oct 6 12:19 mail
drwxr-x--- 2 root nogroup 512 Oct 6 12:21 porn
drwxr-x--- 2 root nogroup 512 Oct 6 12:21 proxy
drwxr-x--- 2 root nogroup 512 Oct 6 12:21 violence
drwxr-x--- 2 root nogroup 512 Oct 6 12:21 warez
Dette så straks bedre ut ;-)
Det som nå må gjøres er noen forandringer i konfigurasjonen til Squid Cache. Åpne squid.conf og legg inn følgende:
# TAG: redirect_program
# Specify the location of the executable for the URL redirector.
# Since they can perform almost any function there isn't one included.
# See the Release-Notes for information on how to write one.
# By default, a redirector is not used.
#
redirect_program /usr/local/bin/squidGuard -c /usr/local/etc/squid/squidGuard.conf
# TAG: redirect_children
# The number of redirector processes to spawn. If you start
# too few Squid will have to wait for them to process a backlog of
# URLs, slowing it down. If you start too many they will use RAM
# and other system resources.
#
redirect_children 5
Pass imidlertid på path'ene til de forskjellige programmer og konfigurasjonsfiler. Hos meg er /usr/local default, men hos deg kan det godt være bare /usr. Spesielt dersom du har brukt en RPM for å legge inn programmene.
Det siste som gjenstår nå er å restarte squid. Dette gjør du enkelt ved å kjøre ' kill -HUP `cat /usr/local/squid/logs/squid.pid` eller 'squid -k reconfigure'. Pass på pathene !
Nå er du klar til å teste sakene. Dette gjør du ved å starte opp en browser (som er konfigurert til å benytte proxy) og legge inn for eksempel http://www.porn.com. Dette skal nå gi deg din egen redirect-side i stedet for det innholdet du ville bli presentert uten squidGuard.
I neste utgave av LINUXmagasinet skal jeg se på noen av de monitoreringsverktøy du kan benytte for å holde et øye med ditt nettverk. Velkommen tilbake da.
|
 |
|
