Hva gjør jeg feil

Generelt .. det viktigste synes jeg det er at et firewall script har en klar logisk struktur slik at det går klart fram hvilke funksjoner det har og hvordan det fungerer. Når tingene blir uoversiktelige så ligger der også en mulighet for feil.

Pleier normalt å anbefale: http://iptables-script.dk/

Man lager et automatisk generert script og så bruker man dette som et utgangspunkt for en videre detaljkonfigurering.

Men til det scriptet som faktisk er lagt ut, dette er den seksjonen som setter opp en delt nat forbindelse:

###############################################################################
## Source NAT -- (SNAT/Masquerading)

    ## Source NAT allows us to "masquerade" our internal machines behind our
    ## firewall. (Examples)

  ##========================================================================##
  ## Static IP address ##
#    $IPTABLES -t nat -A POSTROUTING -o $EXTERNAL -s $INTERNAL_NET \
#        -j SNAT --to-source $EXT_IP

#    $IPTABLES -t nat -A POSTROUTING -o $EXTERNAL -s $DMZ_NET \
#        -j SNAT --to-source $EXT_IP
  ##========================================================================##

  ##========================================================================##
  ## Dynamic IP address ##
#    $IPTABLES -t nat -A POSTROUTING -o $EXTERNAL -s $INTERNAL_NET \
#        -j MASQUERADE

#    $IPTABLES -t nat -A POSTROUTING -o $EXTERNAL -s $DMZ_NET \
#        -j MASQUERADE
  ##========================================================================##


Her inngår faktisk to alternative måter å sette opp dette, men begge ser ut til å være kommentert vekk med det riemlige resultat at nat ikke virker.

Denne seksjonen rettes til:

$IPTABLES -t nat -A POSTROUTING -o $EXTERNAL -s $INTERNAL_NET -j MASQUERADE

Det kan godt være at det finnes andre feil også, men dette er i hvert fall det som er lett synlig ved en gjennomlesning.

Forsøk og legg ut resultatet !

Ellers:

lan->wan skal bruke nat.
lan->dmz skal ikke bruke nat.

Dette blir kanskje umulig (?) dersom det hele skal fungere. Linux benytter 2 forskjellige nat, snat og dnat. (source nat og destination nat)

lan - wan må bruke snat
lan - dmz må bruke dnat
wan - dmz må bruke dnat

(Hvis du med nat mener snat så blir det jo ellers rett.


MVH Langbein

Hei Langbein :)

Takk for hjelpen!

Jeg har satt inn linjen og nå fungerer trafikken fra LAN til internett.

Er all trafikk fra LAN til internet åpen nå?

Har også et annet spørsmål:

Ønsker fra LAN å nå mailserveren som står i DMZ.
Jeg klarer kun å nå den direkte fra firewall boksen.

Mailserveren skal hvis mulig se pc'er i LAN med rikige ip'er.
(Mailserver har IP 80.239.13.169)

Scriptet ligger på http://www.pronav.no/rc.firewall



På forhånd takk :)


Mvh.
Verner

Denne skulle i prinsipp sikre en fri trafikk ut (som hovedregel):

"$IPTABLES -P FORWARD ACCEPT" (Forward policy, dvs default rule settes til ACCEPT, dvs godta pakkene.) (Ser ikke umiddelbart noen andre regler som gir unntak fra denne policy/hovedregel.)

Det tillegs spørmålet om om mail access fra Lan er i virkeligheten et spørsmål som kan være temmelig komplisert og tricky for denne typen 3 port løsninger. Det behøves en del tid for å finne ut av dette .. skal se på det litt senere. (Bruker selv ikke en slik 3 port løsning på grunn av de problemer man vil ha hele tiden når man setter opp nye server funksjoner osv. Har først en 2 port hardware firewall "in front" og så server med innebygget firewall (linux) inne på lan sammen med workstations. Synes det fungerer bra.)

Du kjører en ekstern ip på dmz også, ser jeg nå. Problemene oppstår vel som følge av lokal adresse på dmz, tror jeg. Vil forsøke å se litt på saken, mulig at det ikke er så komplisert allikevell ..

Hei!

Jeg fant feilen på mailserveren.
Måtte sette opp en static route.
( route add 192.168.1.0 mask 255.255.255.0 80.239.13.170 )

Nå fungerer LAN ->WAN & DMZ

Er det kompliert hvis jeg ønsker å sette opp regler for hver tjeneste fra lan til dmz og lan til wan?


Mvh.
Verner


Mvh.
Verner

"route add 192.168.1.0 mask 255.255.255.0 80.239.13.170"

Lar det seg gjøre .. hmm .. interessant .. har pleid å sitte å slite med prerouting rules i iptables. Dette var meget interessant ! Mon dette hadde fungert dersom dmz hadde hatt en intern ip ? Noen ide ?

Når man først har satt opp slik at trafikken kjører både til lan og til van så bør det vel sånn i prinsipp være det enkleste som står tilbake, dvs formulering av firewall rules for denne trafikken.

Det finnes vel i prinsipp hovedsaklig 3 set med rule sets.

1. Ruleset 1, Input chain for lokale prosesser på Firewall maskin.
2. Ruleset 2, Output chain for lokale prosesser på firewall maskin.
3. Rulseset 3, Forward chain for trafikk gjennom firewall/router.

Dessuten så er det mulig å deklarere egne "chains" eller "rulestacs" som disse "grunnfunksjonene" er koplet opp mot. Hvis man benytter seg av dette så kan dette by på fordeler, men det kan også gjøre scriptene noe uleselige.

I det scriptet som du har lagt ut så kan det se ut som om denne konfigureringsmåten er tatt i bruk:

$IPTABLES -N KEEP_STATE
$IPTABLES -F KEEP_STATE

Her står det altså noe slikt som:

1. Lag en ny chain eller ruleset som heter KEEP_STATE
2. Flush dette nye rulsettet, dvs tøm den for alle tilfeldige regler som måtte dukke opp.

Det man så gjør når man utfører konfigurasjonsscriptet, det er at man nærmest kaller disse selvdeklarerte rulesettene som prosedyrekall. Hvis man for eksempel har behov for noen av de samme reglene i Input, output og/eller forward cahin så deklarerer man først et eget ruleset for eksempel "KEEP_STATE" og så lager man et kall eller "jump" til dette rulesettet, og så bruker man reglene tre ganger gjennom slike "kall" i stedet for å programmere det samme 3 ganger.

Dette kan jo by på fordeler men til gjengjeld så kan det å revidere skriptet eller å endre scriptets firewall rules blit til en litt håpløs oppgave, med mindre man har en full oversikt over hele den logiske oppbygningen av denne firewallen og alle de funksjonene som er der.

Jeg går ut fra at du ikke har noen server funksjoner på selve firewall maskinen ? Dette r jo det sikkreste. Dersom man ikke har noen annen inngang til firewall maskinen enn via consoll så er den jo tilnærmet umilig å hacke.

Dersom dette er tilfellet så skal du heller ikke bruke noen andre firewall rules chaines enn forwaring chain vil jeg tro. Da faller jo fordelene ved selvdeklarerte chains bort samtidig som ulempene fortsatt er der.

"Er det komplisert hvis jeg ønsker å sette opp regler for hver tjeneste fra lan til dmz og lan til wan?"

Rent teknisk så er dette forholdsvis enkelt, dersom man så og si holder seg til "grunnfunksjonene" og grunnleggende konfigurasjonsteknikker.

I dette tilfellet så er det vel kanskje litt komplisert fordi utgangspunktet er et nokså komplisert rule set som eventuelt skal modifiseres.

Som "grunnfunksjon" så setter man vel opp en forwarding filtering rule omtrent slik:

iptables -A FORWARD -i eth1 -o eth2  -J ACCEPT
iptables -A FORWARD -i eth2 -o eth1  -J ACCEPT

(Iptables - Append legg til som siste ny regel som sier at all trafikk fra kort 1 og som er rettet mot kort 2 kan få lov til å slippe gjennom)

Mon ikke dette ville gitt fri flyt av trafikk mellom eth1 og eth2 (lan/dmz)?
Videre så vil man kunne diskriminere på visse porter og protokoller mv.

Det vil være vesentlig mere enkelt å lage et script fra bunnen med hensyn til filtrerings rules enn å modifisere det eksisterende scriptet.

Eventult så kunne man heller forsøke å lage et kompakt og enkelt script fra bunne av som først gjør jobben på en korrekt måte, og så der etter forsøke å modifisere prinsippene eller funksjon/virkemåte fra dette enkle scriptet inn i det store scriptet, etterpå, når man først har fått alle funksjonene til å kjøre ver bruk av det første enkle scriptet.

Hvis man for eksempel setter inn en rule som dette i det eksisternde scriptet:

iptables -A FORWARD -i eth1 -o eth2  -J ACCEPT og dette eventuelt fungerer,

Så ville man bypasse de rules som allerede er der og så vil man ende opp med en "konfigureringsspagetti" uten mål og mening.

Hva med å opprette et nytt spørsmål: "Hvordan lage et 3 port firewall script for en Linux router" og så ta det hele fra bunnen av ?

Det vanskeligste og det mest kompliserte i forbindelse med slike multiport firewall scripts det pleier å være å få satt opp routingen rett, og her har du altså en løsning. Firewall rules pleier ikke å være så komplisert, med mindre det skal modifiseres inn i noe annet som er meget komplisert.

Eventuelle eksperten poeng er neppe noen kritisk faktor for et eventuelt nytt spørsmål.

PS ..

Dersom du har tid og mulighet til å ta deg av testingen så kunne det vært ganske praktisk å ha en generell oppskrift på en 3 port Linux firewall liggende på Eksperten.

Har tidligere pleid å sette opp trafikken mellom lan og dmz ved hjelp av prerouting rules i iptables og dette har egentlig fungert såpas dårlig og så tungvint at jeg stort sett har gått bort fra denne løsningen.

Mulig at det kunne gå ann å få til et enkel og bra firewall gateway script med dmz løsning hvis tar utgangspunkt i din løsning for å route trafikk mellom lan og dmz.

(Det neste blir jo stort sett å filtrere denne trafikken rett.)

Jeg roter vel også litt .. for å gjenta meg selv:

Sitat:

Denne skulle i prinsipp sikre en fri trafikk ut (som hovedregel):

"$IPTABLES -P FORWARD ACCEPT" (Forward policy, dvs default rule settes til ACCEPT, dvs godta pakkene.) (Ser ikke umiddelbart noen andre regler som gir unntak fra denne policy/hovedregel.)

Sluttsitat.



Det kan vel rent umiddelbart se ut som om det ikke finnes noen filtering rules for trafikk gjennom routeren overhodet og at den er helt åpne for eksempel inn til serveren til DMZ. Lan klientene vil uansett være beskyttet av NAT.

Forward rules skal sikkre trafikken til fra dmz også og når denne står til accept så blir det vel full åpning.

"Moral": når firewall script blir store og uoversiktelige da får dette ofte noen konsekvenser man først ikke legger merke til.

Mener at det er en god ide å lage et nytt script som gir dmz servene en beskyttelse.

Alternativer:

1. Enten så kan du bare la dmz stå open og så kan du konfigurere input firewall på server, hvis dette er en Linux. Det er meget enkelt.

2. Eller så kan vi lage et script fra bunne av, slik som foreslått.

3. Intallert heller en didikert firewall Linux distribusjon dersom du uansett har en dedikert Linux firewall boks.

Ad alt 3. Dersom du setter opp smoothwall så har den alle disse tingene ferdig som standard via et web basert grafisk konfigurasjonsgrensenitt. Meget enkel.
http://www.smoothwall.org

Forbehold: Har ikke prøvd smoothwall med global ip på dmz. Regner med at det går bra.

Jeg blir med på å lage et nytt script fra bunnen av dersom du eventuelt oppretter et nytt spørsmål for dette.

Er du der !?

Dette var temmelig interessant ..

Har nå printet ut og gått gjennom 2 port og 3 port løsningen som ligger på web samt dokumentasjonen.

Det finnes detaljløsninger som ser ut til å være meget interesante og meget bra.

Det ser på den annen side ut til å være grunnleggende designfeil i både 2 ports og 3 ports varienten.

Det er utarbeidet et omfattende regelsett for å kontrollere ip pakkene på et "sted" i linux kernel der den aktuelle trafikken aldri vil passere forbi. (Dataflowen skjedde på denne måten som scriptene ser ut til å forutsette hos Linux kernel 2.2.x men ikke hos 2.4.x og 2.6.x der dataflowen og prisnippene for filtrering er lagt helt om.)

Utskriften av den opprinnelige 3 port firewall er på 17 sider.

Fordi disse rules filtrerer "på et annet sted" enn der datatrafikken "passerer forbi" i 2.4.x og 2.6.x kernel så vil så vidt jeg kan se ingen av disse reglene fordelt på 17 sider ha noen effekt. (Eventuelt med unntak av dem som går på kernelkonfigurering.)

For din firewall så vil dette sansynligvis ha den effekt at serveren på dmz blir stående helt ubeskyttet ut mot internett. Klienten på Lan vil uansett være beskyttet av at det dreier seg om en nat løsning og lokale adresser. Man vil i utgangspunktet ikke kunne komme inn fra Internett.

Selve firewall maskinen selv ser ut til å være beskyttet.

Tilbudet om å forsøke å bygge opp en 3 port firewall fra bunnen av gjelder fortsatt. Da kunne sikkert veldig mye av denne 17 sideren brukes om igjen forutsatt at grunndesignen blir slik at datapakkene i det hele blir veiet mot de rules som gjelder.

Kan være jeg tar feil, men synes i alle fall det kan være gunstig å se litt nærmere på denne saken.

langbein> der skal bruges en del timer på at nærlæse scriptet - det må blive i aften - men jeg er helt enig i, at det er lidt voldsomt . og uoverskueligt.

Personligt bruger jeg http://monmotha.mplug.org/firewall/index.php - jeg har dog ikke gennemgået det på samme måde, så det indeholder måske også fejl.

Han skriver selv, at dmz ikke virker selvom han har et par linier omkring det.

Hei langbein,

Ønsker gjerne å være med å lage og teste ut en 3 ports løsning.
Jeg oppretter et nytt spørsmål.



Mvh.
Verner

Ok, da gjør vi det !! :)

Håper dere begge to blir med på prosjektet.
Regner med at Lap sitter inne med en del detaljkunnskap som jeg ikke har.
(Litt probelemer med routingen, slik som jacov har løst den i dette eksemplet
her. Har ikke full sjekk på problemstillingene rundt "mangle" og bruker den normalt
ikke. Mon den egentlig skulle være der ?)

Pleier normalt å lage firewall på den måte at man "prototyper", først så lager man en "grunnstruktur" som er meget enkel og som inneholder alle basisfunksjonene. Der etter at grunnfunksjonene er testet ut så bygger man opp de øvrige detaljfunksjonene
mens man tester ut for riktig funksjon, sted for steg.

Foreslår at alle de detaljene som kan "forstyrre helhetsbildet" eventuelt blir føyd til til slutt.