Da skal det vel fortsatt være global adresse på serveren går jeg ut fra ?!
Her er det jo snakk om et subnett av globale adresser.
Problemstilling 1: Hva slags subnet er nå dette og hvor mange ip inneholder dette, hva blir netverksnummrene, hva blir gateway nummerene når man lager en ny 3 port, hva blir broadcastnummrene ?
Hvordan er dette egentlig i dag, mht disse problemstillingene, og hvordan blir dette etter modifikasjonen til 3 port ?
Noen som tar den på sparket ?
Lan kjører jo vanlig nat så den skulle jo være ukomplisert.
Hva slags effekt får egentlig dette ? Blir det en permanent endring eller er dette noe som forsvinner når maskinen rebooter ?
Hvordan griper dette inn i forhold til firewall rules ? Hvordan virker det ? Hvorfor bruker man vanligvis ikke et slikt oppsett i forbindelse med Linux firewalls ? Hvorfor bruker man vanligvis iptables prerouting command i stedet ?
Spørsmål: Det kompliserte ifb med en slik 3 port løsning det er jo skille mellom den trafikken som skal ut fra lan til dmz kontra den som skal fra lan og ut til internett.
Går ut i fra at man det både skal være mulig å accessere mail server på dmz og på internett slik at firewall må vite å skille mellom når trafikk ut skal til internett og når den skal ut til dmz.
Den må kunne route den samme typen trafikk to forskjellige retninger, ut til internett eller ut til dmz avhengig av hvilken ip som adresseres. Stemmer dette ?
Synes godt om
Slettet bruger
20. september 2004 - 18:01#11
vi kan se bort fra denne ekstra rutingen ved et nytt oppsett. Routen var kun lagt til siden jeg kjørte et parallellt oppsett til bedriftens nett. Så lenge mailserveren har brannveggen som default gateway vil det fungere.
(For å legge inn en slik route permanent bruker man (-p) på nt/win2k)
Verner
Synes godt om
Slettet bruger
20. september 2004 - 18:23#12
Det stemmer.
Mailserveren skal være tilgjengelig fra både lan og internett.
Det ligger ikke noe problemstilling i å gjøre mailserveren tilgjengelig fra internet og fra lan.
Problemet er når maskinene på lan i noen tilfeller skal kontakte mail serveren på dmz og i andre tilfeller så skal de kontakte mailservere på internett. Dersom man setter opp en ordinær regel som sender requesten inn på dmz, da mister lan klienten muligheten til å sende den samme requesten til internet og motsatt. (Når dette gjøres "på enkleste måte" via iptables.)
Det som jeg kanskje så for meg som en mulighet det var at denne "route varianten" kanskje kunne få den effekt at denne problemstillingen mer eller mindre ble borte ved at serverne på lan ble "transparent synlig" for lan klientene akkurat som en hvilken som helst annen ekstern ip adresse.
Vil tro at dette er mulig, men at dette kanskje kan få den bieffekt at filtering rules bypasses for trafikk fra lan til dmz. Lan vil kanskje få full access til alle portene på server Jeg vet ikke at det er slik, uten å teste, bare en "gjett".
Når det gjelder filtering inn til lan og filtering inn til dmz, så bør dette uansett virke som normalt.
Kanskje interessant å lage to script, en på hver av metodene, forwarding via iptables og routing via "rout" slik at man kan se på likheter og forskjell.
# Vi setter policies, dvs default rules. # Samtlige porter stenges normalt i utgangspunktet for all trafikk. # I løpet av testingen saa kan input output staa aapen. De skal likkes senere.
iptables -P INPUT DROP iptables -P OUTPUT DROP iptables -P FORWARD DROP
# Sette opp prerouting fra LAN til DMZ for mail trafikk # Og her er problemet .. Lan mister mulighet til aa accessere mail server på nett. # Alle mail requester sendes til DMZ iptables -t nat -A PREROUTING -i eth2 -p tcp --dport 25 -j DNAT --to 80.239.13.170:25 iptables -t nat -A PREROUTING -i eth2 -p tcp --dport 110 -j DNAT --to 80.239.13.170:110 iptables -t nat -A PREROUTING -i eth2 -p tcp --dport 143 -j DNAT --to 80.239.13.170:143
# Saa var det dette med en delt internttforbindelse til lan iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE
# Eventulle aapninger inn til lokale serverprosesser paa firewall pc # Stengt her står det ingen ting
# Eventuelle aapninger ut fra lokale prosesser paa firewall pc # Stengt her staar det ingen ting.
# Sa langt er firewall helt stengt, vi må lage noen store eller smaa aapninger # Trafikkretning ut fra Lan til internet: # Denne skulle gi lan full access til Internet og til DMZ. Forelopig for testing, OK # Senere så kan man aapne for en og en port hvis man oensker det iptables -A FORWARD -i eth2 -j ACCEPT
# Returtrafikken fra internett må slippes tilbake til lan. Benytter statefull inspection. # lager forelopig en felles statefull inspection løsning iptables -A FORWARD -m state --state ESTABLISHED,RELATED -j ACCEPT
# Så må det til noen åpninger inn til dmz for trafikk fra LAN: iptables -A FORWARD -i eth0 -o eth0 -p tcp --dport 25 -j ACCEPT iptables -A FORWARD -i eth0 -o eth0 -p tcp --dport 110 -j ACCEPT iptables -A FORWARD -i eth0 -o eth0 -p tcp --dport 143 -j ACCEPT
# Servere på DMZ må kunne svare på requester, statefull inspection retning ut # Dette er tatt vare paa i den forelopige statefull inspection losningen.
# Serverne på DMZ maa kunne sende mail # Kun en port åpen ut, ikke lett aa vare trojan ! iptables -A FORWARD -i eth1 -o eth0 -p tcp --dport 25 -j ACCEPT # I denne forbindelse maa den kunne svare paa returtrafikk, men den generelle # statefull inspection rule bor kunne ta seg av dette, i hvert fall inntil videre.
Så må det til noen åpninger inn til dmz for trafikk fra LAN: iptables -A FORWARD -i eth0 -o eth0 -p tcp --dport 25 -j ACCEPT iptables -A FORWARD -i eth0 -o eth0 -p tcp --dport 110 -j ACCEPT iptables -A FORWARD -i eth0 -o eth0 -p tcp --dport 143 -j ACCEPT
Går ut, erstattes med:
# Så må det til noen åpninger inn til dmz for trafikk fra WAN/Internett: iptables -A FORWARD -i eth0 -o eth1 -p tcp --dport 25 -j ACCEPT iptables -A FORWARD -i eth0 -o eth1 -p tcp --dport 110 -j ACCEPT iptables -A FORWARD -i eth0 -o eth1 -p tcp --dport 143 -j ACCEPT
Forresten .. Ved 2 port firewall så filtrerer man alltid den gjennomstrømmende trafikk via forwarding rules. Mon det skulle gjøre seg gjeldende noen helt andre prinsipper for en 3 port firewall. (Slik at man må bruke input / output chain.) Ville i utgangspunktet ikke tro det, men ..
Det generelle hovedprinsippet for 2.4.x/2.6.x kernel det er jo all datatrafikk som "flyter gjennom" via iptables/netfilter filtreres via forwarding chain og ikke input / output chain slik som for 2.2.x kernel.
Men hva skjer egentlig med den trafikken som skjer via "rout". Hvordan fitreres denne egentlig, via hvilke chains ?
# Vi setter policies, dvs default rules. # Samtlige porter stenges normalt i utgangspunktet for all trafikk. # I løpet av testingen saa kan input output staa aapen. De skal likkes senere.
iptables -P INPUT DROP iptables -P OUTPUT DROP iptables -P FORWARD DROP
# Sette opp prerouting fra LAN til DMZ for mail trafikk # Og her er problemet .. Lan mister mulighet til aa accessere mail server på nett. # Alle mail requester sendes til DMZ # iptables -t nat -A PREROUTING -i eth2 -p tcp --dport 25 -j DNAT --to 80.239.13.170:25 # iptables -t nat -A PREROUTING -i eth2 -p tcp --dport 110 -j DNAT --to 80.239.13.170:110 # iptables -t nat -A PREROUTING -i eth2 -p tcp --dport 143 -j DNAT --to 80.239.13.170:143
# Saa var det dette med en delt internttforbindelse til lan iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE
# Eventulle aapninger inn til lokale serverprosesser paa firewall pc # Stengt her står det ingen ting
# Eventuelle aapninger ut fra lokale prosesser paa firewall pc # Stengt her staar det ingen ting.
# Sa langt er firewall helt stengt, vi må lage noen store eller smaa aapninger # Trafikkretning ut fra Lan til internet: # Denne skulle gi lan full access til Internet og til DMZ. Forelopig for testing, OK # Senere så kan man aapne for en og en port hvis man oensker det iptables -A FORWARD -i eth2 -j ACCEPT
# Returtrafikken fra internett må slippes tilbake til lan. Benytter statefull inspection. # lager forelopig en felles statefull inspection løsning iptables -A FORWARD -m state --state ESTABLISHED,RELATED -j ACCEPT
# Så må det til noen åpninger inn til dmz for trafikk fra Wan internett: iptables -A FORWARD -i eth0 -o eth1 -p tcp --dport 25 -j ACCEPT iptables -A FORWARD -i eth0 -o eth1 -p tcp --dport 110 -j ACCEPT iptables -A FORWARD -i eth0 -o eth1 -p tcp --dport 143 -j ACCEPT
# Servere på DMZ må kunne svare på requester, statefull inspection retning ut # Dette er tatt vare paa i den forelopige statefull inspection losningen.
# Serverne på DMZ maa kunne sende mail # Kun en port åpen ut, ikke lett aa vare trojan ! iptables -A FORWARD -i eth1 -o eth0 -p tcp --dport 25 -j ACCEPT # I denne forbindelse maa den kunne svare paa returtrafikk, men den generelle # statefull inspection rule bor kunne ta seg av dette, i hvert fall inntil videre.
# Vi setter policies, dvs default rules. # Samtlige porter stenges normalt i utgangspunktet for all trafikk. # I løpet av testingen saa kan input output staa aapen. De skal likkes senere.
iptables -P INPUT DROP iptables -P OUTPUT DROP iptables -P FORWARD DROP
# Sette opp prerouting fra LAN til DMZ for mail trafikk # Og her er problemet .. Lan mister mulighet til aa accessere mail server på nett. # Alle mail requester sendes til DMZ. Haer maa event bygges opp noe videre logikk. iptables -t nat -A PREROUTING -i eth2 -p tcp --dport 25 -j DNAT --to 80.239.13.170:25 iptables -t nat -A PREROUTING -i eth2 -p tcp --dport 110 -j DNAT --to 80.239.13.170:110 # iptables -t nat -A PREROUTING -i eth2 -p tcp --dport 143 -j DNAT --to 80.239.13.170:143
# Saa var det dette med en delt internttforbindelse til lan iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE
# Eventulle aapninger inn til lokale serverprosesser paa firewall pc # Stengt her står det ingen ting
# Eventuelle aapninger ut fra lokale prosesser paa firewall pc # Stengt her staar det ingen ting.
# Sa langt er firewall helt stengt, vi må lage noen store eller smaa aapninger # Trafikkretning ut fra Lan til internet: # Denne skulle gi lan full access til Internet og til DMZ. Forelopig for testing, OK # Senere så kan man aapne for en og en port hvis man oensker det iptables -A FORWARD -i eth2 -j ACCEPT
# Returtrafikken fra internett må slippes tilbake til lan. Benytter statefull inspection. # lager forelopig en felles statefull inspection løsning iptables -A FORWARD -m state --state ESTABLISHED,RELATED -j ACCEPT
# Så må det til noen åpninger inn til dmz for trafikk fra Wan internett: iptables -A FORWARD -i eth0 -o eth1 -p tcp --dport 25 -j ACCEPT iptables -A FORWARD -i eth0 -o eth1 -p tcp --dport 110 -j ACCEPT iptables -A FORWARD -i eth0 -o eth1 -p tcp --dport 143 -j ACCEPT
# Servere på DMZ må kunne svare på requester, statefull inspection retning ut # Dette er tatt vare paa i den forelopige statefull inspection losningen.
# Serverne på DMZ maa kunne sende mail # Kun en port åpen ut, ikke lett aa vare trojan ! iptables -A FORWARD -i eth1 -o eth0 -p tcp --dport 25 -j ACCEPT # I denne forbindelse maa den kunne svare paa returtrafikk, men den generelle # statefull inspection rule bor kunne ta seg av dette, i hvert fall inntil videre.
Tenker ellers litt på å sette opp en 3 port gateway selv for testing.
Et slikt firewall script fungerer nesten alltid litt forskjellig fra det man har tenkt. Det er i hvert fall min erfaring. Med 2 port så er det jo rimelig greit. Med 3 port så er det en del å hode styr på dersom lan skal kunne bruke dmz med rett filtrering samtidig som man skal ha full internetttilgang fra lan.
Største delen av arbeidet med å lage en firewall det ligger i det å gjennomføre en systematisk uttestning og kartlegging av firewallfunksjonene.
Tror at en del kernels nå begynner å støtte string inspection, dvs datainnholdet i pakkene, slik at man også kunne ha lagt inn dette. Kan være nyttig for å beskytte servere. http://www.securityfocus.com/printable/infocus/1531
jeg er lidt i tvivl om, at du ikke komplicerer det unødigt?
public adresses in total (80.239.13.160/255.255.255.240)
i dag: public WAN (cisco/zyxel) (80.239.13.160/255.255.255.248) public WAN/DMZ (zyxel/zyxel) (80.239.13.168/255.255.255.248)
linux setup (uden zywall-10/zywall-1) eth0 = Internet (80.239.13.172/255.255.255.248) eth1 = DMZ (80.239.13.168/255.255.255.248) eth2 = LAN (192.168.1.0/255.255.255.0)
Set fra LAN-siden, så vil en åben trafik til f.eks. port 25 (som vi plejer at gøre i iptables) automatisk skabe en route fra eth2 -> eth1, da source er eth2 og der er ikke behov for MASQUERADE.
Udfordringen findes i, at iptables skal tillade indgående trafik til eth1/port 25 er tilladt. Hvis mailserver også kører web-access skal der også være adgang til 80/443 - kunne vel være:
Har ikke sett noe til dette problemet med at lan mister mulighet for tilkobling til mailserver på internett. ref. tekst under
# Sette opp prerouting fra LAN til DMZ for mail trafikk # Og her er problemet .. Lan mister mulighet til aa accessere mail server på nett. # Alle mail requester sendes til DMZ
Mvh. Verner
Synes godt om
Slettet bruger
21. september 2004 - 21:20#37
# Forelopig kladd. Utgave 0.00000000001
# eth0 = LAN # eth1 = WAN # eth2 = DMZ ## (mailserver ip = 80.239.13.169 ##
# Vi setter policies, dvs default rules. # Samtlige porter stenges normalt i utgangspunktet for all trafikk. # I løpet av testingen saa kan input output staa aapen. De skal likkes senere.
iptables -P INPUT DROP iptables -P OUTPUT DROP iptables -P FORWARD DROP
# Sette opp prerouting fra LAN til DMZ for mail trafikk # Og her er problemet .. Lan mister mulighet til aa accessere mail server på nett. # Alle mail requester sendes til DMZ iptables -t nat -A PREROUTING -i eth0 -p tcp --dport 25 -j DNAT --to 80.239.13.169:25 iptables -t nat -A PREROUTING -i eth0 -p tcp --dport 110 -j DNAT --to 80.239.13.169:110 iptables -t nat -A PREROUTING -i eth0 -p tcp --dport 143 -j DNAT --to 80.239.13.169:143
# Saa var det dette med en delt internttforbindelse til lan iptables -t nat -A POSTROUTING -o eth1 -j MASQUERADE
# Eventulle aapninger inn til lokale serverprosesser paa firewall pc # Stengt her står det ingen ting
# Eventuelle aapninger ut fra lokale prosesser paa firewall pc # Stengt her staar det ingen ting.
# Sa langt er firewall helt stengt, vi må lage noen store eller smaa aapninger # Trafikkretning ut fra Lan til internet: # Denne skulle gi lan full access til Internet og til DMZ. Forelopig for testing, OK # Senere så kan man aapne for en og en port hvis man oensker det iptables -A FORWARD -i eth0 -j ACCEPT
# Returtrafikken fra internett må slippes tilbake til lan. Benytter statefull inspection. # lager forelopig en felles statefull inspection løsning iptables -A FORWARD -m state --state ESTABLISHED,RELATED -j ACCEPT
# Så må det til noen åpninger inn til dmz for trafikk fra WAN/Internett: iptables -A FORWARD -i eth1 -o eth2 -p tcp --dport 25 -j ACCEPT iptables -A FORWARD -i eth1 -o eth2 -p tcp --dport 110 -j ACCEPT iptables -A FORWARD -i eth1 -o eth2 -p tcp --dport 143 -j ACCEPT
# Servere på DMZ må kunne svare på requester, statefull inspection retning ut # Dette er tatt vare paa i den forelopige statefull inspection losningen.
# Serverne på DMZ maa kunne sende mail # Kun en port åpen ut, ikke lett aa vare trojan ! iptables -A FORWARD -i eth2 -o eth1 -p tcp --dport 25 -j ACCEPT # I denne forbindelse maa den kunne svare paa returtrafikk, men den generelle # statefull inspection rule bor kunne ta seg av dette, i hvert fall inntil videre.
gad vide hvorfor reglerne omkring port 25/110/143 overses. Jeg vil tro, at det er almindelig routning som er årsagen til, at du alligevel kommer i kontakt med mailserveren.
Men i forhold til ovenstående kan de 3 regler fjernes.
Som regel er problemet med ftp, at modulet ip_conntrack_ftp ikke er loaded - prøv at indsætte:
eller endnu bedre: insmod ip_conntrack_ftp insmod ip_nat_ftp
Synes godt om
Slettet bruger
21. september 2004 - 21:41#40
Har feilet litt i testen min.
All mail trafikk uansett adresse havner på mailserveren i dmz. Beklager at jeg ikke så dette. Da stemmer problemet som er beskrevet under.
# Sette opp prerouting fra LAN til DMZ for mail trafikk # Og her er problemet .. Lan mister mulighet til aa accessere mail server på nett. # Alle mail requester sendes til DMZ
langbein> jeg tror scriptet skal (i version "# Forelopig kladd. Utgave 0.00000000002") ikke forsøge at PREROUTING/DNAT til mailserveren. Trafikken burde (efter min viden) ende det korrekte sted uden nat.
komprimeret udgave: #send trafik default til eth1 iptables -t nat -A POSTROUTING -o eth1 -j MASQUERADE #accepter frafik fra eth0 iptables -A FORWARD -i eth0 -j ACCEPT #returtrafik er ok iptables -A FORWARD -m state --state ESTABLISHED,RELATED -j ACCEPT #adgang til 4 porte fra WAN -> DMZ iptables -A FORWARD -i eth1 -o eth2 -p tcp --dport 25 -j ACCEPT iptables -A FORWARD -i eth1 -o eth2 -p tcp --dport 80 -j ACCEPT iptables -A FORWARD -i eth1 -o eth2 -p tcp --dport 110 -j ACCEPT iptables -A FORWARD -i eth1 -o eth2 -p tcp --dport 143 -j ACCEPT #tillad mail trafik ud fra mailserver iptables -A FORWARD -i eth2 -o eth1 -p tcp --dport 25 -j ACCEPT
det ser faktisk ud til, at det er en dmz-firewall som findes på linket - alt inklusive - som kan bruges i ovenstående løsning. Det er en kombination af userdefined chains og proxyarp.
Men har vi ikke et problem med den/de eksterne ip som ligger på dmz ?
Vil ikke en ip pakke som kommer utenfra i utgangspuktet ikke vite om at den først skal passere forbi ip firewalls eksterne ip for der etter å nå fram til sitt mål på server. Mon ikke dette ligger konfigurert inn i Cico 1601 ? Mon det også vil virke slik at routingen via 3 port løsningen vil virke likt slik at man av denne grunn allerede har en ferdig oppsatt routing fram til dmz serverene.
Kan dette være rett forstått ?
Så langt skulle behovet for prerouting for trafikk utenfra ikke være til stede, forutsatt at dette er rett forstått.
Dersom man ser på teorien rundt netfilter / ipfilter så kan det se ut som om preroting er den "funksjon" som sender trafikken inn til forwarding chains, slik at uten prerouting så har man også bypassed alle firewall rules, av de rules som er satt opp til nå.
Refererer for eksempel til Rusty ryssel sine HowTo's vedrørende iptables.
Nå er det på den annen side ikke sikkert at teorien i dette tilfellet er i samsvar med virkeligheten. Det kan for esempel tenkes at den teorien man finner i disse howtos og andre steder på nett er så forenklet at den gir et feil inntrykk i forhold til denne 3 port løsningen.
Det finnes jo sånn sett bare en "fasit" på slike problemstillinger. Det er å lage en hypotese for hvordan det kanskje kan virke, og så lage en praktisk utprøving av om det virker slik eller slik.
Man må vel i all enkelhet lage en praktisk utprøving av om firewall er tett eller ikke tett, når den skal være tett, og om den slipper gjennom når den skal slippe gjennom i de trafikkretninger og på den måte som man ønsker.
Routing decision skal jo ligge i prerouting eller i postrouting og dersom trafikken utenfra og inn til dmz ikke passerer gjennom hverken preroting eller postrouting, hva er det da som sender den gjennom forwarding chain / stack ?
Men hensikten med denne det var bare å kamuflere firewall maskinen, ikke å sette opp et alternativ til et packet filter slik som jeg aller hurtigst leste det til å være ? http://www.sjdjweis.com/linux/proxyarp/
Så kjører min 3 port gateway .. forsøker å få testet litt i morgen :)
Synes godt om
Slettet bruger
22. september 2004 - 08:24#48
langbein> du har rett angående rutingen av trafikk til mailserveren.
Config hentet fra Cisco: ip route 80.239.13.168 255.255.255.248 80.239.13.163
Mailtrafikk inn fra internett vil derfor bli rutet til mailserveren gjennom den brannvegggen/ruteren som befinner seg på 80.239.13.163. Etterhvert kan jeg bytte ut wan ip slik at denne serien befinner seg bak linuxboksen istedenfor Zyxel ruteren.
Takker for info. Det gjenstår å se hvordan dette reelt sett fungerer i en firewall sammenheng. Holder på med å kople om nettverket og å legge inn dmz firewall..
Ellers, kjenner du til denne:
For å sjekke nåværende status for firewall innput og output chain:
"iptables -L -n"
For å sjekke status for firewall forwarding filter:
"iptables -t nat -L -n"
Har du en portscanner ? Har du også en mulighet for å scanne deg selv utenfra og inn (fra internett) og fra lan mot dmz ?
Synes godt om
Slettet bruger
22. september 2004 - 12:53#50
Mail fungerer både til dmz og internett når jeg kommenterer vekk følgende:
Har akkurat satt opp firewall og og fått trafikken til å flyte gjennom, både til internett og til dmz. Men har ikke rukket å sette opp noen avgrensning i form av filtere. Det er ganske åpent.
Når det gjelder portscanning så spørs det om du rent reelt sett scanner riktig ip ? (fra grc.com)
Når det gjelder Linux så har jo denne en innebygget portscanner (hvis den er installert) som heter nmap (forsøk "man nmap"). Ellers så finnes det en ganske ok gratis portscanner for Windows som heter Superscan. Synes den gamle versjonen var mye bedre enn den som kom senere. Freeware. Kan sende den hvis du har en mail.
Mitt oppsett er litt annerledes, ved at jeg nå i testsammenheng har satt opp 2 stk nat firewalls i serie. Den første er den som er innebygget i adsl modem og den neste er så en 3 port firewall basert på Suse Linux (Det var de CD'ene jeg fant først.)
Selv om oppsettet er forkjellig så mener jeg at de fleste priinsippene som relateres til selve firewallfunksjonen i 3 port routeren er stort sett er de samme.
Vedrørende lan: er det akseptabelt at lan har full tilgang til alle porter på dmz ? (Skulle i hvert fall vært interessant å sett på hvordan man eventuelt kunne unngå dette.)
Når man scanner en server så skal man selvfølgelig ikke få som resultat at alle portene er stelth. De portene som er serverporter må da være åpne, (enten man scanner dirrekte elelr gjennom en firewall) men det var kanskje underforstått ?
Synes godt om
Slettet bruger
22. september 2004 - 14:12#54
Portscanning fra grc scanner selve firewall ip'en 80.239.13.162. Jeg ser at nmap er installert og skal teste det ut.
Det er akseptablet at lan har full tilgang til dmz, men jeg er enig i at det hadde vært interessant å funnet en metode som begrenset det til kun nødvendige porter.
Ønsker også å begrense lan til internett trafikk.
Du kan sende scanneren på adressen briggveien@yahoo.no
Takk for infoen!
Synes godt om
Slettet bruger
22. september 2004 - 14:22#55
Forstår. Siden mailserveren fremdeles står bak Zyxel ruteren må jeg vente med portscanning fra internett til dmz til jeg har skiftet wan ip på linuxboksen.
# Vi setter policies, dvs default rules. # Samtlige porter stenges normalt i utgangspunktet for all trafikk. # I løpet av testingen saa kan input output staa aapen. De skal likkes senere.
# Saa var det dette med en delt internttforbindelse til lan iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE
Firewall står helt åpen og det er en delt internettforbindelse ut via eth0. Noen porter er prerouted inn til server på LAN. At firewall er helt åpen kommer av at de tre hovedpolicies er satt til ACCEPT. Det neste er jo å stenge disse helt, sette de til DROP, og så sette opp et antall mest mulig presise "små hull" i firewall som tillater akkurat den trafikk som skal tillates og ingen ting annet.
Prinsippielt så må man også gjøre et valg om man vil satse på en dynamisk eller statefull inspection løsning eller en statisk firewall. Statisk er vel mest robust, men samtidig mest åpen. For statefull inspection så kan man jo lage mer presise regler, samtidig som det på den annen side tidligere har vært avslørt muligheter for å bryte gjennom stateful ruleset. Dette har jo blitt tettet, men man vet jo egentlig ikke hva som kommer ..
Statefull er jo lettest å sette opp, fordi det er færre detaljer å tenke på.
Drt var jo ellers rett at lan og dmz kan se hverandre og at sikkerheten mellom disse to segmentene, i utgangspunktet, ved at de ser hverandre, er lik null. (Men det kan jo også være OK hvis man har kontroll på klientene.)
Dersom firewall står helt åpen, og man har en routing forbindelse mellom lan og dmz (eventuelt ute fra internett og inn på server, dette blir vel samme grunnprinsipp), hvilken chain / rulestack passerer den routede trafikken gjennom, input chain, output chain, forwarding chain, eller ingen av dem.
Dersom man har consoll tilgang slik at man ikke stenger seg ute (det vil skje hvis man bruker ssh) så bør man vel kunne eksperimentere ved å bare sette de 3 policies, en for en til "Drop".
Da bør man kunne se svaret, hvilke chain som virker i forhold til routed trafikk, en to eller ingen ??
(Vil prøve når jeg kommer hjem og har consoll tilgang.)
Man kan selvfølgelig ha mange forskjellige script liggende i et directory, slik at man kan veksle på hvilke man kjører. Det er alltid greit å ha et "firewallopen" script i det tilfellet at alle ting stanser opp.
Synes godt om
Slettet bruger
22. september 2004 - 18:30#58
Har prøvd å begrense tilgangen fra lan til Internett, og lan til dmz ved å erstatte: iptables -A FORWARD -i eth2 -j ACCEPT
med følgende: # tester regelverk for trafikk fra lan til internett # iptables -A FORWARD -i eth0 -o eth1 -p tcp --dport 21 -j ACCEPT iptables -A FORWARD -i eth0 -o eth1 -p tcp --dport 53 -j ACCEPT iptables -A FORWARD -i eth0 -o eth1 -p udp --dport 53 -j ACCEPT iptables -A FORWARD -i eth0 -o eth1 -p tcp --dport 80 -j ACCEPT iptables -A FORWARD -i eth0 -o eth1 -p tcp --dport 110 -j ACCEPT iptables -A FORWARD -i eth0 -o eth1 -p tcp --dport 443 -j ACCEPT
# tester regelverk for trafikk fra lan til dmz # iptables -A FORWARD -i eth0 -o eth2 -p tcp --dport 23 -j ACCEPT iptables -A FORWARD -i eth0 -o eth2 -p tcp --dport 80 -j ACCEPT iptables -A FORWARD -i eth0 -o eth2 -p udp --dport 110 -j ACCEPT iptables -A FORWARD -i eth0 -o eth2 -p tcp --dport 143 -j ACCEPT
Dette ser ut til å fungere etter hensikten.
Synes godt om
Slettet bruger
22. september 2004 - 18:35#59
Mener erstattet: iptable -A FORWARD -i eth0 -j ACCEPT (eth0=lan)
Hvis disse reglene skal ha noen effekt så må FORWARD policy stå til stengt. (DROP)
Desuten så må det også finne en eller flere statefull inspection regler som sørger for å åpne dynamisk for den aktuelle returtrafikken. Når man sender ut en request på tcp port 80, så vil man jo få tilbake et svar på en helt annen port i den uprioriterte portrekken, dvs over 1024 (tror jeg det var).
Man kan for eksempel åpne dynamisk for returtrafikken ved hjelp av denne: iptables -A FORWARD -m state --state ESTABLISHED,RELATED -j ACCEPT
Vedrørende hvilken chain som er i bruk eller ikke er i bruk ifb med filtreringen av trafikk mellom lan og dmz..
Det viser seg at også denne trafikken passerer gjennom forwarding chains mens den ikke er innom input eller output chains, den filtreres faktisk likt med den trafikken som sendes gjennom forwarding chains via pre- og postrouting.
Denne "systematikk" eller "ensartethet" i måten dataflowen skjer på, det medfører så vidt jeg kan se at det er mulig å lage en slik 3 port Linux firewall som er meget sikker. (INPUT / OUTPUT kan stenges 100 % slik at det ikke er mulig å nå inn til de lokale prosessene på noen annen måte enn via console, hacking av selve firewall maskinen blir tilnærmet umulig.)
Det gjør det også ganske greit å sette opp rules både for den inngående og den utgående trafikk og trafikken mellom lan og dmz.
De tingene som ble lagt inn av lap over, ser ellers ut til å være 100 % korrekt, ut i fra det som jeg kan bedømme.
rart at routed trafik paserer på "normal" vis - det gør det jo etop nemmere. Den 3port firewall produceres på basis af regler og routning - og linket (proxyarp) er blot en anden tilgang.
Hvis du/I mener at jeg skal levere noget, så må I sige til - ellers lytter jeg mest med (jeg er da også interesseret i ovenstående - og kunne måske bruges i forbindelse med iptables.1go.dk -> make a 3port firewall).
Mon det ikke fungerer. Hele endringen for å kjøre med global ip på dmz det blir bare i all enkelhet å ta vekk preroting setningene fordi den ordinære routing virker på samme måte i forhold til de globale adressene. Filtreringen blir også lik.
Scriptet er testet ut (sånn noenlunde tror jeg) på en nat forbindelse, dvs med lokale adresser. For den annen anvendelse med global ip så skulle det altså bare bli å endre til de ønskede porter og så ta vekk alle preroting setningene.
Tar gjerne i mot kommentarer på eventuelle feil eller annet.
# 3 Port Linux firewall revisjon 0.9
# Rediger eventuelt om i scriptet # slik at det passer (eth0, eth1, eth2) # Har aldri likt å bruke tekststrenger # eth0 = WAN # eth1 = LAN # eth2 = DMZ
# Delt internttforbindelse til lan iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE
# Statefull inspection, dynamisk åpning for returtrafikk iptables -A FORWARD -m state --state ESTABLISHED,RELATED -j ACCEPT
# Fitrering av trafikk fra Internet til DMZ iptables -A FORWARD -i eth0 -o eth2 -p tcp --dport 25 -j ACCEPT iptables -A FORWARD -i eth0 -o eth2 -p udp --dport 53 -j ACCEPT iptables -A FORWARD -i eth0 -o eth2 -p tcp --dport 80 -j ACCEPT iptables -A FORWARD -i eth0 -o eth2 -p tcp --dport 110 -j ACCEPT iptables -A FORWARD -i eth0 -o eth2 -p tcp --dport 143 -j ACCEPT
# Filtrering, trafikkretning internet lan: # Lukket for all inngående trafikk untatt returtrtafikk via statefull inspection.
# Filtrering, trafikkretning lan internet # Alternativ 1 full aapning iptables -A FORWARD -i eth1 -o eth0 -j ACCEPT
# Alternativ 2 man restrikter denne utgaaende trafikken fra lan til internett # iptables -A FORWARD -i eth1 -o eth0 -p tcp --dport 20 -j ACCEPT # iptables -A FORWARD -i eth1 -o eth0 -p tcp --dport 21 -j ACCEPT # iptables -A FORWARD -i eth1 -o eth0 -p tcp --dport 22 -j ACCEPT # iptables -A FORWARD -i eth1 -o eth0 -p tcp --dport 25 -j ACCEPT # iptables -A FORWARD -i eth1 -o eth0 -p udp --dport 53 -j ACCEPT # iptables -A FORWARD -i eth1 -o eth0 -p tcp --dport 80 -j ACCEPT # iptables -A FORWARD -i eth1 -o eth0 -p tcp --dport 110 -j ACCEPT # iptables -A FORWARD -i eth1 -o eth0 -p tcp --dport 143 -j ACCEPT
# Filtrering av trafikk fra lan til dmz # Alternativ 1, full åpning: iptables -A FORWARD -i eth1 -o eth2 -j ACCEPT
#Alternativ 2 filtrering av trafikken fra lan til dmz # iptables -A FORWARD -i eth1 -o eth2 -p tcp --dport 25 -j ACCEPT # iptables -A FORWARD -i eth1 -o eth2 -p udp --dport 53 -j ACCEPT # iptables -A FORWARD -i eth1 -o eth2 -p tcp --dport 80 -j ACCEPT # iptables -A FORWARD -i eth1 -o eth2 -p tcp --dport 110 -j ACCEPT # iptables -A FORWARD -i eth1 -o eth2 -p tcp --dport 143 -j ACCEPT
#Filtrering av trafikk fra server-dmz til lan # Her skal det ikke gaa noen annen trafikk enn returtafikk. iptables -A FORWARD -i eth2 -o eth1 -j ACCEPT
# Filtrering av trafikk fra server til internett # Alternativ 1. full aapning iptables -A FORWARD -i eth2 -o eth0 -j ACCEPT
# Alternativ 2. filtrert trafikk fra server til internett # iptables -A FORWARD -i eth2 -o eth0 -p tcp --dport 25 -j ACCEPT # iptables -A FORWARD -i eth2 -o eth0 -p udp --dport 53 -j ACCEPT
# Og saa til slutt saa lager vi en mulighet for ssh paalogging fra lan # Dette kan godt redigeres vekk dersom man vil ha maksimal sikkerhet. # Man får da bare konsolltilgang. iptables -A INPUT -i eth1 -p tcp --dport 22 -j ACCEPT # Og dynamisk aapning for ssh returtrafikken fra lan iptables -A OUTPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
#Filtrering av trafikk fra server-dmz til lan # Her skal det ikke gaa noen annen trafikk enn returtafikk. iptables -A FORWARD -i eth2 -o eth1 -j ACCEPT
Det er vel ikke "returtrafik" der åbnes for her - men al trafik. Den tidligere "state related" klarer vel dette?
proxyarp: baserer sig på, at firewall "faker" dmz-adresserne på internet interface (altså svarer for portene) set for netværket, men sender trafikken ind på dmz. Funktionen er også kendt fra f.eks. cisco routere, hvor ikke-routbar tratik kan routes på et wan-link (f.eks. dhcp-requests).
# Her skal det ikke gaa noen annen trafikk enn returtafikk. iptables -A FORWARD -i eth2 -o eth1 -j ACCEPT
Det er vel ikke "returtrafik" der åbnes for her - men al trafik. Den tidligere "state related" klarer vel dette?
**************
Jo, dette var en feil .. holdt på med noe feilsøking skulle åpne midlertidig og så og så glemte jeg å ta den vekk, - takker !
**************
"firewall "faker" dmz-adresserne på internet interface" - er det ip adressene eller er det hardware adressene den faker ? Forutsetter denne løsningen globale ip på serverne ? Behøver internet interfase og server eventuelt å kjøre på forskjellig subnet ? (Dette minner jo litt om problemstillingene rundt ebtables / bridging firewall.)
state related for ssh .. jo det ville jeg da tro er nødvendig så lenge output ellers er stengt. ssh er vel tcp og da må det åpner for retur via output. Skal teste for sikekrhets skyld.
Har testet - mistet forbindelsen umiddelbart da jeg tok vekk statefull inspection for ssh.
Dette skyldes jo at ssh kjører via input / output chain slik at denne får en "statefull logikk" som ligger helt utenfor den som gjelder for forwarding logikken. Derfor så bør hele denne ssh komminikasjonen blokkeres eller stenges ned dersom man har konsol tilgang. (Men i en test og utviklingsfase så er det jo greit å ha den.)
Skal vi se. Retter opp den ene feilen og tar bort muligheten for ssh pålogging:
# 3 Port Linux firewall revisjon 0.9
# Rediger eventuelt om i scriptet # slik at det passer (eth0, eth1, eth2) # Har aldri likt å bruke tekststrenger # eth0 = WAN # eth1 = LAN # eth2 = DMZ
Og for den konkrete anvendelse, med global ip på dmz, portene rettes til slik at det passer. Kortnumrene redigeres også om slik at det passer:
# 3 Port Linux firewall revisjon 0.9
# Rediger eventuelt om i scriptet # slik at det passer (eth0, eth1, eth2) # Har aldri likt å bruke tekststrenger # eth0 = WAN # eth1 = LAN # eth2 = DMZ
Hvordan går det ? (Tenker litt på å demontere 3 port routeren og gjøre klart for neste prosjekt .. (2 port bridging firewall/ebtables/kernel 2.6))
Synes godt om
Slettet bruger
24. september 2004 - 10:04#74
Den fungerer meget bra.
Takk for hjelpen langbein og lap!
Jeg ønsker å bruke ssh mot firewallen. Tilgangen skal kun skje fra min lokale ip adresse gjennom lan interface. Vil det bety mye for sikkerheten om jeg åpner for dette?
iptables -A INPUT -i eth1 -p tcp --dport 22 -j ACCEPT # Og dynamisk aapning for ssh returtrafikken fra lan iptables -A OUTPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
Er det mulig å begrense setningen over til kun å gjelde port 22?
Slipp inn alle ip pakkker som er addresert til port 22 til de lokale prosesser på firewall maskinen forutsatt at de kommer inn vi netverksadapter eth1, dvs de er fra lan. "Tillatelsen til trafikk" gjelder bare port 22 og trafikkretning inn fra lan til lokale prosesser på firewall maskin det vil i dette tilfellet si SSH server.
Jeg hadde ellers en veldig merkelig "småbugs" synes jeg når jeg brukte denne:
iptables -A INPUT -i eth1 -p tcp --dport 22 -j ACCEPT # Og dynamisk aapning for ssh returtrafikken fra lan iptables -A OUTPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
så fikk jeg en veldig langsom ssh pålogging, ved at den brukte veldig lang tid på å godkjenne passordet. Er ikke sikker på hvorfor dette skjer, men jeg kom da inn eter litt venting. Kan tenkes at dette bare gjelder Suse installasjonen. Tror ikke dette egentlig skulle ha skjedd (forsinkelsen), men det skjer allikevell.
Det betyr nok i praksis ikke noe for sikkerheten å åpne for en ssh tilgang fra LAN. (Ut fra en veldig teoretisk betrakning så kan man jo hevde det, men i praksis så er dette ikke noen probelmstilling. Har man behov for ssh tilgang fra lan så setter man opp dette.)
iptables -A OUTPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
Dette er en standard måte å åpne dynamisk for returtrafikk fra de lokale prosessene fra de lokale prosessene. Her ligger det nok kanskje en teoretisk rissiko, som kanskje til og med kan være reel, men i praksis så er det vel stort sett akseptabelt.
Synes godt om
Slettet bruger
27. september 2004 - 15:21#77
Hvordan åpner jeg for dhcp mot lan?
Blir det INPUT chain siden det er lokalt på firewall?
# Vi setter policies, dvs default rules. # Samtlige porter stenges normalt i utgangspunktet for all trafikk.
iptables -P INPUT DROP iptables -P OUTPUT DROP iptables -P FORWARD DROP
# Saa var det dette med en delt internttforbindelse til lan iptables -t nat -A POSTROUTING -o eth1 -j MASQUERADE
# Eventulle aapninger inn til lokale serverprosesser paa firewall pc # Stengt her står det ingen ting iptables -A INPUT -i eth0 -p tcp --dport 22 -s 192.168.1.0/24 -j ACCEPT IPTABLES -A INPUT -i eth0 -p tcp --sport 68 --dport 67 -s 192.168.1.0/24 -j ACCEPT # lan dhcp IPTABLES -A INPUT -i eth0 -p udp --sport 68 --dport 67 -s 192.168.1.0/24 -j ACCEPT # lan dhcp iptables -A OUTPUT -m state --state ESTABLISHED,RELATED -j ACCEPT # Stengt her staar det ingen ting.
# Sa langt er firewall helt stengt, vi må lage noen store eller smaa aapninger # Trafikkretning ut fra Lan til internet:
# regelverk for trafikk fra lan til internett # iptables -A FORWARD -i eth0 -o eth1 -p tcp --dport 21 -j ACCEPT #telnet iptables -A FORWARD -i eth0 -o eth1 -p tcp --dport 22 -j ACCEPT #ssh iptables -A FORWARD -i eth0 -o eth1 -p tcp --dport 23 -j ACCEPT #ftp iptables -A FORWARD -i eth0 -o eth1 -p tcp --dport 53 -j ACCEPT #dns oppslag iptables -A FORWARD -i eth0 -o eth1 -p udp --dport 53 -j ACCEPT #dns oppslag iptables -A FORWARD -i eth0 -o eth1 -p tcp --dport 80 -j ACCEPT #http web iptables -A FORWARD -i eth0 -o eth1 -p tcp --dport 110 -j ACCEPT # **pop3 åpen med tvil ** iptables -A FORWARD -i eth0 -o eth1 -p tcp --dport 119 -j ACCEPT #news iptables -A FORWARD -i eth0 -o eth1 -p tcp --dport 143 -j ACCEPT # **imap åpen med tvil ** iptables -A FORWARD -i eth0 -o eth1 -p tcp --dport 443 -j ACCEPT #https web # regelverk for trafikk fra lan til internett #
# regelverk for trafikk fra lan til dmz # iptables -A FORWARD -i eth0 -o eth2 -p tcp --dport 25 -j ACCEPT #smtp mail iptables -A FORWARD -i eth0 -o eth2 -p tcp --dport 80 -j ACCEPT #http webmail client iptables -A FORWARD -i eth0 -o eth2 -p tcp --dport 110 -j ACCEPT #pop3 iptables -A FORWARD -i eth0 -o eth2 -p tcp --dport 143 -j ACCEPT #imap iptables -A FORWARD -i eth0 -o eth2 -p tcp --dport 443 -j ACCEPT #https webmail client iptables -A FORWARD -i eth0 -o eth2 -p tcp --dport 465 -j ACCEPT #ssl-smtp iptables -A FORWARD -i eth0 -o eth2 -p tcp --dport 993 -j ACCEPT #ssl-imap iptables -A FORWARD -i eth0 -o eth2 -p tcp --dport 995 -j ACCEPT #ssl pop3 iptables -A FORWARD -i eth0 -o eth2 -p tcp --dport 3389 -j ACCEPT #eksternt skrivebord iptables -A FORWARD -i eth0 -o eth2 -p tcp --dport 22111 -j ACCEPT #promail tjeneste # regelverk for trafikk fra lan til dmz #
# Returtrafikken fra internett må slippes tilbake til lan. Benytter statefull inspection. # lager forelopig en felles statefull inspection løsning iptables -A FORWARD -m state --state ESTABLISHED,RELATED -j ACCEPT
# Så må det til noen åpninger inn til dmz for trafikk fra WAN/Internett: iptables -A FORWARD -i eth1 -o eth2 -p tcp --dport 25 -j ACCEPT #smtp mail iptables -A FORWARD -i eth1 -o eth2 -p tcp --dport 80 -j ACCEPT #http webmail client iptables -A FORWARD -i eth1 -o eth2 -p tcp --dport 110 -j ACCEPT #pop3 iptables -A FORWARD -i eth1 -o eth2 -p tcp --dport 143 -j ACCEPT #imap iptables -A FORWARD -i eth1 -o eth2 -p tcp --dport 443 -j ACCEPT #https webmail client iptables -A FORWARD -i eth1 -o eth2 -p tcp --dport 465 -j ACCEPT #ssl-smtp iptables -A FORWARD -i eth1 -o eth2 -p tcp --dport 993 -j ACCEPT #ssl-imap iptables -A FORWARD -i eth1 -o eth2 -p tcp --dport 995 -j ACCEPT #ssl pop3 iptables -A FORWARD -i eth1 -o eth2 -p tcp --dport 22111 -j ACCEPT #promail tjeneste
# Servere på DMZ må kunne svare på requester, statefull inspection retning ut # Dette er tatt vare paa i den forelopige statefull inspection losningen.
# Serverne på DMZ maa kunne sende mail og sjekke dns oppslag. iptables -A FORWARD -i eth2 -o eth1 -p tcp --dport 23 -j ACCEPT #ftp nedlasting virus def. + sw. iptables -A FORWARD -i eth2 -o eth1 -p tcp --dport 25 -j ACCEPT #smtp mail iptables -A FORWARD -i eth2 -o eth1 -p tcp --dport 53 -j ACCEPT #dns oppslag iptables -A FORWARD -i eth2 -o eth1 -p udp --dport 53 -j ACCEPT #dns oppslag iptables -A FORWARD -i eth2 -o eth1 -p tcp --dport 80 -j ACCEPT #http nedlasting (windows update) iptables -A FORWARD -i eth2 -o eth1 -p tcp --dport 110 -j ACCEPT #multipop sjekk av eksterne pop kontoer
# I denne forbindelse maa den kunne svare paa returtrafikk, men den generelle # statefull inspection rule bor kunne ta seg av dette, i hvert fall inntil videre.
Her har vi vel inn/ut til de lokale prosessene på firewall maskin:
iptables -A INPUT -i eth0 -p tcp --dport 22 -s 192.168.1.0/24 -j ACCEPT IPTABLES -A INPUT -i eth0 -p tcp --sport 68 --dport 67 -s 192.168.1.0/24 -j ACCEPT # lan dhcp IPTABLES -A INPUT -i eth0 -p udp --sport 68 --dport 67 -s 192.168.1.0/24 -j ACCEPT # lan dhcp iptables -A OUTPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
Hvordan fungerer ssh påloggingen ? Den blir ikke hengende 10-20 sekunder slik som det skjedde hos meg ? (Tror dette egentlig var en "tilfeldig" bugs.)
Når det gjelder SSH, er det helt sikkert og innlysende at dette bare er en serverfunksjon som bare krever mulighet for kontakt fra klient til server ? Mon det ikke også er nødvendig for "server" å kunne ta kontakt ut til klienten "på selvstendig initiativ" ? Husker ikke, bare en slags "følelse".
For feilsøking forsøk å sett output policy midlertidig til ACCEPT:
iptables -P OUTPUT ACCEPT
Vil forøke å sjekke litt på hvordan trafikken til fra dhcp server egentlig kjører. Godt mulig jeg tar feil.
Ellers - den "sikre" måten å konfigurere en firewall på, det er jo å først la trafikken flyte gjennom en packet sniffer via en åpen firewall og så dumpe/lese all den trafikken som passerer. Når man kjenner til eksakt hvilken trafikk som skal passere, så konfigurerer man firewall til å slippe gjennom akkurat denne trafikken. http://www.ethereal.com
Synes godt om
Slettet bruger
28. september 2004 - 18:24#83
ssh får forbindelse etter ca. 2 sekunder.
Har testet firewallen med bare meg som bruker og da fungerer den godt uten å kutte forbindelsen. Det virker som den stenger all trafikk og trenger en reboot for å fungere igjen.
Det skjedde i går når jeg og en kolega koblet oss på messenger. Samtidig sjekket jeg imap mail konto. Etter en reboot fungerte den en stund før den igjen kuttet forbindelsen. Kan det være noe med NAT oppsettet?
Er det noe jeg kan sjekke på konsolet når dette oppstår?
Har sjekket med en av firewallbøkene mine vedrørende DHCP. Så vidt jeg kan lese ut fra Robert Ziegler Linux firewalls 2'nd edition så kan DHCP server ikke kjøre med så enkel konfigurering som den over. Det ser bla ut til å være rett at man er avhengig av å åpne for et langt mer komplekst trafikkmønster der også DHCP server kan ta initiativet til trafikk ut mot klientene.
Fra hans firewall eksempelkonfigurering:
############################################################### # Accessing a Local DHCP Server (UDP Ports 67, 68)
Det at ssh serveren virket var en interessant opplysning, for jeg mente nemlig det at det faktisk var uten fornuftig grunn at min hang i opptil 20 sek under pålogg med firewall på. Etter pålogg så kjørte den som normalt.
Feil source nat for delt internettforbindelse har jeg ingen tro på. Det har nok heller noe å gjøre med for restriktive filtreringsregler i en eller annen sammenheng.
Mener at det å ha en DHCP server på firewall kanskje ikke er den beste ide. Her kan man jo alternativt bruke en eller annen liten "boks" eller en pentium 166 inne på lan.
På den annen side, dersom gateway kan kommunisere fritt ut til lan og den har udp port 67/68 pluss statefull insp på inngående så skulle der vel også kunne kjøre ?
OK. Har ingen dhcp kjørende. Den er ikke åpen på 67/68 begge veier ?? (Har ikke prøvd dette i praksis, i hver fall ikke som jeg husker, men synes nesten bøkene tyder på noe slikt.)
Skulle det kunne la seg gjøre å sette opp en 3 port firewall med DMZ basert på bridging firewall prinsippet, der man ikke router trafikken inn mot DMZ, men der DMZ faktisk er en del av det "ytre" subnet ??!!
Det høres jo nesten litt "absurd" ut, men mon dette ikke skulle kunne la seg gjøre ?
For et praktisk tilfelle som dette, så ville dette i så fall kunne medføre, skulle man tro for eksempel at:
1. Den første Cisco routeren blir "overflødig" (?!) 2. Et subnet på 8 ip gir 6 tilgjengelige "brukbare" ip der man for eksempel kan bruke 1 ip til lan og 5 ip til forskjellige servere på DMZ
Man ville eventuelt ikke lengere ha behov for så mange eksterne ip at man kan dele opp i subnet ?! (for å opnå DMZ med ekstern ip)
En litt spesiell problemstilling vil det jo bli rundt nat funksjonen og deling av ip, da en eventuell 3 port bridging firewall (uten ip) vel i utgangspunktet ikke vil være i stand til å håntere dette.
Man kunne selvfølgelig sette en nat enhet bak en 3 port bridging firewall ..
En annen "teoretisk" løsning ..
Man setter samtidig opp en routing firewall inn mot lan, som har nat funksjon og en bridging firewall inn mot dmz slik at man ender opp samtidig med en bridging firewall inn mot dmz og en routing firewall in mot lan.
Men her blir det et lite tankekors .. bridging firewall har jo ingen ip og da kan den jo ikke natte .. (Eller kan man gi den en ip slik at den allikevell kan natte ??)
Så en annen teoretisk variant .. tre port firewall blir til fireport firewall.
To av kortene utgjør bridging firewall uten ip som filtrerer trafikk til LAN og DMZ. Kort no 3 og 4 utgjør nat routing firewall (med ip) som filtrerer trafikk inn til lan. Man måtte eventuelt legge opp kablingen slik at trafikken først passerer forbi bridging firewall. Så må man i prinsipp sette opp en switch mellom de to firewalls, der man kopler opp DMZ serverne. Der i fra så kopler man videre opp mot routing firewall og inn mot lan.
(Prinsipp: "2 seriekoplede firewalls i den samme boks")
Mon om dette skulle være teknisk mulig og om det finnes kommersielle firewalls som utnytter et slikt prinsipp ??!!
Ved nærmere ettertanke .. den tenkte 4 port varianten .. da skal jo data i så fall komme inn gjennom et kort ut gjennom et annet, og så skal de samme data passere i en lop tilbake inn gjennom et annet kort og gjennom den samme kernel på nytt .. det skal være usagt om dette skal kunne la seg gjøre .. godt mulig at det ikke går.
Beklager .. dette ble visst litt for fantasifullt. Har prøvd 3 port løsning med bridge til DMZ og router til LAN. Dette fungerte IKKE.
Det som på det annen side vel må være rimelig sikkert, det er at man kan sette opp en bridiging og en routing firewall opp i serie på denne måten (Men det må være på 2 PC bokser):
På denne måte skulle det da være mulig å utnytte 6 eksterne ip i et subnet på 8 slik at opp til 6 ip kan være eksternt tilgjengelige (Den siste må i såfall fungere som kombinert gateway server hvis ikke så blir det 5 tilgjengelige server adresser.)
Jeg har været hårdt arbejdsramt den sidste uge - derfor ikke rigtig nogen kommentarer. Det er utroligt hvad du kan få brygget sammen, men ja, man burde være i stand til at udnytte alle 6 ip-adresser.
Jeg synes du skulle lave en artikel omkring dette - du har jo fortjent nogle points - jeg opretter også gerne et ? til dig - nu har jeg ikke været særlig aktiv i tråden - og du har brugt mange timer.
Det utrolige med Linux, det er at uansett hva man leser om av kommersielle løsninger innfor firewalling og sikkerhet, så er det mulig å implementere de samme prinsipenene, mer eller mindre, og for det meste, i en linuxdistribusjon man laster gratis ned fra nettet og en gammel PC - Dette er jo utrolig interessant.
Jeg jobber ikke innefor ikt/data, men heller et beslektet område (industriell automasjon), slik at det er veldig interessant å få noen tilbakemeldinger fra dere som er mer direkte involvert i "virkelig" datadrift. Ellers så har jo det hele kanskje litt lett for å få et litt "lærebok og labororatorieaktig" preg.
Dette med points kan vel ikke være spesielt viktig. Jeg har fått hjelp mange ganger når jeg har stått fast med ting her på eksperten, og det er vel i grunnen det som er det viktige. Det er også veldig bra å få testet ut det som man ikke har en praktisk mulighet for å få testet ut selv.
Ellers for den aktuelle 3 ports løsningen (Den som spørsmålet egentlig handler om).
Vi har satt opp en del porter til å være åpne og noen til å være lukket. Det ligger jo en del beskyttelse i dette. Det som vi ikke har satt opp det er en form for beskyttelse i forhold til de portene som står åpene. (Dette er vel kanskje noe av den største rissiko, angrep mot server gjennom porter som normalt skal være åpne.)
En type angrep i denne kategori det er jo såkalt "synflood", dvs en kraftig strøm av ip pakker der syn bit er satt i alle pakkenene. (Dette vil jo ikke skje på denne måten ved normal kommunikasjon, det ville vel være snakk om en strøm av spoofede ip.)
Fant noe ferdig som kanskje kan brukes:
## Put in a syn flood rule to stop people from a DOS attack ## Commented out while testing things iptables -N syn-flood iptables -A FORWARD -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 DROP
Kilden virker "troverdig" og jeg mener også å ha sett denne kodesnutten tidligere på andre steder.
Må eventuelt settes inn tidlig før de andre forwarding rules.
Har ikke testet og kan derfor ikke garantere resultatet.
Dersom du/dere/noen tester ut dette med en "dos protection", kan dere da legge ut en beskjed i det minste om syntaksen kjører og om forbindelsen fortsatt fungerer !? (Selve dos protection er det jo ikke så lett å få prøvd ut) (dos - denial of service attack)
Håper jeg ikke forvirrer (i for stor grad) med alle mulige innspill.
Jeg har testet dos attack koden over. Ingen tvil om at den fungerer, men den fungerer litt annerledes enn jeg trodde. Den sjekker ikke på noe syn flagg, den sjekker raten på alle slags inngående pakker. På denne måten så kan man sikkre at ikke en hacker kjører ned en serverfunksjon ved å overbelaste input rate for en server funksjonen.
--limit-burst betyr vel maks 4 pakker pr sekund, tror jeg (??).
Da jeg satte inn en slik firewall funksjon på min inngående adsl linke (2 MB) så skjedde det at store websider begynte å komme inn langsomt. Ved å sette burst rate så kunne jeg faktisk styre hastigheten på innkommende trafikk. Ved burst 2 så sto trafikken nesten stille. Ved burst rate 10 så kjørte det sånn noenlunde som normalt. Satte den helt opp til 20 for å beholde normal speed, og samtidig holde funksjonen intakt for testingens skyld.
Går det elles bra med 3 port løsningen ??
Hvis ønskelig så kan det jo også redigeres inn burst limit / dos attach protection øverst i FORWARDING chain.
Sjekk alle pakker med syn bit satt, godta en "steady flow" på 2 pakker per sekund, godta også burst (plustelig trafikkbelastning) på opp til 4 pakker.
Synes godt om
Slettet bruger
03. oktober 2004 - 22:40#97
Hei!
3 port løsningen fungerer meget bra. Har lagt til beskyttelsen mot syn-flood, men måtte justere den opp litt. Hvordan legger man til beskyttelse mot dos attach? Er det noen andre beskyttelser vi også bør legge til?
syn-flood og dos attach, det blir vel i prinsipp slik som jeg ser det stort sett det samme. Jeg måtte ellers også justere "flowen" litt opp for at det skulle kjøre ok. (Men ut i fra dette så ser man jo faktisk at det fungerer.)
I denne stningen:
iptables -N syn-flood
så står det jo at man skal definere et nytt regelsett som heter "syn-flood" (Navnet kunne like godt vært "ole-olsen" eller "dos-attach", det ville vel fungere likt.)
I denne setningen:
iptables -A FORWARD -p tcp --syn -j syn-flood
så velger man at det er alle ip pakker med syn bit satt som skal sjekkes nærmere for "rate" og "burst" fordi dette er typiske pakker for et dos angrep (slik som jeg forstår dette.) Man kunne gode endre dette utvalgskriteriet ved for eksempel å sjekkke alle tcp pakker uansett bit/flagg setting hvis man mener dette er mer effektivt. (Som i alle andre sikkerhetssammenhenger så blir det å balansere problemstillingen rundt sikkerhet mot funksjonalitet og performance.)
Andre beskyttelser, jo et regelsett som fjerner "forfalskede" eller "spoofede" ip pakker der flaggene er satt på en "umulig" måte som ikke kan opptre ved vanlig trafikk.
Har hatt muliugheten til å sitte å se online på at hackere har jobbet mot en server som jeg har stående på et server senter i utlandet, og her kan jeg faktisk se at denne framgangsmåten er i bruk. Antar at det er for å forsøke å lure logikken i firewall eller i server. Har hemntet inn et regelsett fra Robert Ziegler sin Linux firewall bok som må/bør plasseres helt framme i scriptet, enten rett etter setting av policies eller event rett etter syn-flood regelene.
Fra min siste "kladd":
# Samtlige policies settes til drop, dvs stengt. iptables -P INPUT DROP iptables -P OUTPUT DROP iptables -P FORWARD DROP
# Forhindre DOS attack iptables -N syn-flood iptables -A FORWARD -p tcp --syn -j syn-flood # iptables -A FORWARD -p tcp --tcp-flags SYN SYN -j syn-flood iptables -A syn-flood -m limit --limit 4/s --limit-burst 8 -j RETURN iptables -A syn-flood -j DROP
# Droppe spoofede pakker iptables -A FORWARD -p tcp --tcp-flags ALL NONE -j DROP iptables -A FORWARD -p tcp --tcp-flags SYN,FIN SYN,FIN -j DROP iptables -A FORWARD -p tcp --tcp-flags SYN,RST SYN,RST -j DROP iptables -A FORWARD -p tcp --tcp-flags FIN,RST FIN,RST -j DROP iptables -A FORWARD -p tcp --tcp-flags ACK,FIN FIN -j DROP iptables -A FORWARD -p tcp --tcp-flags ACK,PSH PSH -j DROP iptables -A FORWARD -p tcp --tcp-flags ACK,URG URG -j DROP
Jacov -> Kan du legge ut hele firewall scriptet for 3 port løsningen etter at du har laget de endringene som du event ønsker, slik at vi får fram et mer oversiktlig sluttressultat ?!
Regelsettet over hindrer for en stor del også portscanning. Da jeg testet det hjemme så var jeg ikke lengere i stand til å portscanne ut til min egen server på server senter så lenge disse reglene kjørte. (De er jo bidireksjonale, dvs de virker likt begge trafikkretninger.)
Synes godt om
Slettet bruger
04. oktober 2004 - 15:35#99
Her er scriptet med mine modifikasjoner. Har lagt til noe i forbindelse med logging.
# Vi setter policies, dvs default rules. # Samtlige porter stenges normalt i utgangspunktet for all trafikk. iptables -P INPUT DROP iptables -P OUTPUT DROP iptables -P FORWARD DROP
# Definerer egene chains # iptables -N tcpflags iptables -A tcpflags -m limit --limit 15/minute -j LOG --log-prefix TCPflags: iptables -A tcpflags -j DROP
iptables -N firewalled iptables -A firewalled -m limit --limit 15/minute -j LOG --log-prefix Firewalled: iptables -A firewalled -j DROP
iptables -N syn-flood iptables -A FORWARD -p tcp --syn -j syn-flood iptables -A syn-flood -m limit --limit 16/s --limit-burst 24 -j RETURN iptables -A syn-flood -j LOG --log-prefix SynFloodAttack: iptables -A syn-flood -j DROP
# definerer ugyldige tcp-flags # iptables -A FORWARD -p tcp --tcp-flags ALL FIN,URG,PSH -j tcpflags iptables -A FORWARD -p tcp --tcp-flags ALL ALL -j tcpflags iptables -A FORWARD -p tcp --tcp-flags ALL SYN,RST,ACK,FIN,URG -j tcpflags iptables -A FORWARD -p tcp --tcp-flags ALL NONE -j tcpflags iptables -A FORWARD -p tcp --tcp-flags SYN,RST SYN,RST -j tcpflags iptables -A FORWARD -p tcp --tcp-flags SYN,FIN SYN,FIN -j tcpflags
# Saa var det dette med en delt internttforbindelse til lan iptables -t nat -A POSTROUTING -o eth1 -j MASQUERADE
# Eventulle aapninger inn til lokale serverprosesser paa firewall pc # Stengt her står det ingen ting iptables -A INPUT -i eth0 -p tcp --dport 22 -s 192.168.1.0/24 -j ACCEPT iptables -A OUTPUT -m state --state ESTABLISHED,RELATED -j ACCEPT # Stengt her staar det ingen ting.
# Sa langt er firewall helt stengt, vi må lage noen store eller smaa aapninger # Trafikkretning ut fra Lan til internet:
# regelverk for trafikk fra lan til internett # iptables -A FORWARD -i eth0 -o eth1 -p tcp --dport 21 -j ACCEPT #telnet iptables -A FORWARD -i eth0 -o eth1 -p tcp --dport 22 -j ACCEPT #ssh iptables -A FORWARD -i eth0 -o eth1 -p tcp --dport 23 -j ACCEPT #ftp iptables -A FORWARD -i eth0 -o eth1 -p tcp --dport 53 -j ACCEPT #dns oppslag iptables -A FORWARD -i eth0 -o eth1 -p udp --dport 53 -j ACCEPT #dns oppslag iptables -A FORWARD -i eth0 -o eth1 -p tcp --dport 80 -j ACCEPT #http web iptables -A FORWARD -i eth0 -o eth1 -p tcp --dport 110 -j ACCEPT #pop3 iptables -A FORWARD -i eth0 -o eth1 -p tcp --dport 119 -j ACCEPT #news iptables -A FORWARD -i eth0 -o eth1 -p tcp --dport 143 -j ACCEPT #imap iptables -A FORWARD -i eth0 -o eth1 -p tcp --dport 443 -j ACCEPT #https web # regelverk for trafikk fra lan til internett #
# regelverk for trafikk fra lan til dmz # iptables -A FORWARD -i eth0 -o eth2 -p tcp --dport 25 -j ACCEPT #smtp mail iptables -A FORWARD -i eth0 -o eth2 -p tcp --dport 80 -j ACCEPT #http webmail client http iptables -A FORWARD -i eth0 -o eth2 -p tcp --dport 110 -j ACCEPT #pop3 iptables -A FORWARD -i eth0 -o eth2 -p tcp --dport 143 -j ACCEPT #imap iptables -A FORWARD -i eth0 -o eth2 -p tcp --dport 443 -j ACCEPT #https webmail client https iptables -A FORWARD -i eth0 -o eth2 -p tcp --dport 465 -j ACCEPT #ssl-smtp iptables -A FORWARD -i eth0 -o eth2 -p tcp --dport 993 -j ACCEPT #ssl-imap iptables -A FORWARD -i eth0 -o eth2 -p tcp --dport 995 -j ACCEPT #ssl pop3 iptables -A FORWARD -i eth0 -o eth2 -p tcp --dport 3389 -j ACCEPT #eksternt skrivebord iptables -A FORWARD -i eth0 -o eth2 -p tcp --dport 22111 -j ACCEPT #promail tjeneste # regelverk for trafikk fra lan til dmz #
# Returtrafikken fra internett må slippes tilbake til lan. Benytter statefull inspection. # lager forelopig en felles statefull inspection løsning iptables -A FORWARD -m state --state ESTABLISHED,RELATED -j ACCEPT
# Så må det til noen åpninger inn til dmz for trafikk fra WAN/Internett: iptables -A FORWARD -i eth1 -o eth2 -p tcp --dport 25 -j ACCEPT #smtp mail iptables -A FORWARD -i eth1 -o eth2 -p tcp --dport 80 -j ACCEPT #http webmail client iptables -A FORWARD -i eth1 -o eth2 -p tcp --dport 110 -j ACCEPT #pop3 iptables -A FORWARD -i eth1 -o eth2 -p tcp --dport 143 -j ACCEPT #imap iptables -A FORWARD -i eth1 -o eth2 -p tcp --dport 443 -j ACCEPT #https webmail client iptables -A FORWARD -i eth1 -o eth2 -p tcp --dport 465 -j ACCEPT #ssl-smtp iptables -A FORWARD -i eth1 -o eth2 -p tcp --dport 993 -j ACCEPT #ssl-imap iptables -A FORWARD -i eth1 -o eth2 -p tcp --dport 995 -j ACCEPT #ssl pop3 iptables -A FORWARD -i eth1 -o eth2 -p tcp --dport 22111 -j ACCEPT #promail tjeneste
# Servere på DMZ må kunne svare på requester, statefull inspection retning ut # Dette er tatt vare paa i den forelopige statefull inspection losningen.
# Serverne på DMZ maa kunne sende mail og sjekke dns oppslag. iptables -A FORWARD -i eth2 -o eth1 -p tcp --dport 23 -j ACCEPT #ftp nedlasting virus def. + sw. iptables -A FORWARD -i eth2 -o eth1 -p tcp --dport 25 -j ACCEPT #smtp mail iptables -A FORWARD -i eth2 -o eth1 -p tcp --dport 53 -j ACCEPT #dns oppslag iptables -A FORWARD -i eth2 -o eth1 -p udp --dport 53 -j ACCEPT #dns oppslag iptables -A FORWARD -i eth2 -o eth1 -p tcp --dport 80 -j ACCEPT #http nedlasting (windows update) iptables -A FORWARD -i eth2 -o eth1 -p tcp --dport 110 -j ACCEPT #multipop sjekk av eksterne pop kontoer
# I denne forbindelse maa den kunne svare paa returtrafikk, men den generelle # statefull inspection rule bor kunne ta seg av dette, i hvert fall inntil videre.
# AApner for loopback interface # iptables -A INPUT -i lo -j ACCEPT
# Drop & log regel # iptables -A INPUT -j firewalled
# aktiverer ip forwarding # echo 1 > /proc/sys/net/ipv4/ip_forward
Mon jeg har oppdaget en "morsom" (funny) effekt av reglene over (?)
Når man portscanner en range på for eksempel 10000 porter så kommer den (scanneren) opp med (en feil) beskjed om at samtlige porter er lukket. Scanner man i en liten portrange for eksempel port 75-85 så kommer den opp med beskjed om at port 80 er åpen.
Dersom dette er riktig, og denne "effekten" lar seg "verifisere" så vil jo dette være særdeles nyttig i en sikkerhetsmessig sammenheng. Mon det virkelig er slik at åpne porter blir "stelth" eller usynlig for en portscanner ???!! (Hadde noen sagt dette til meg for noen timer siden så hadde jeg ment det var umulig.)
Mon dette kan være en effekt av syn-flood "mekanismen", dvs at en ordinær scanning gir en slik støm av data som er slik at syn-flood mekanismen går i midlertidig lås slik at portene blir usynlige. Det kan også tenkes å ha noe med reglene under avsnitt spoofede pakker å gjøre.
Har du/dere mulihet for å sjekke at det er riktig at portscan blir blokkert ??
Det er ellers også noen andre problemstillinger rundt det med Linux systemvariabler, men det er liksom "et nytt kapittel" i det hele. Har ikke pleid å ta så mye hensyn til denne problemstillingen fram til nå. Mulig jeg oppretter et nytt spørsmål om dette.
Synes godt om
Slettet bruger
04. oktober 2004 - 15:54#103
Jeg har prøvd å kjøre test på mailserver fra grc.com, men den tester bare firewall ip. Kan du teste fra deg? Du finne mailserveren på ip: 80.239.13.169
Hadde vært en kjempe fordel hvis portene hadde sett ut som stelth. Siden vi har en 2 Mbit linje måtte jeg justere opp verdiene en del, men klarer fremdeles å få trigget regelen ved f.eks å kjøre speedometeret til itavisen.no Hastigheten gjennom boksen ser bra ut.
Se der ja, det virker med å stelthe porter !! Det er bare det at du har så store verdier for flow/burst at den kommer delvis gjennom. Sjekket en mindre range 23-28 og da dukket plutselig port 25 opp !!
Har testet og sjekket litt på dette med systemparametre. Konklusjonen er den at man med fordel kan legge inn et avsnitt i scriptet som lager en "hardening" av selve operativsystemet på firewall gateway. Dette scriptavsnittet settes helt øverst. Legg ellers merke til det som står i siste avsnitt. Selve skriptavsnittet kan kopieres inn fra den øverste delen av spørsmålet.
Tilladte BB-code-tags: [b]fed[/b] [i]kursiv[/i] [u]understreget[/u] Web- og emailadresser omdannes automatisk til links. Der sættes "nofollow" på alle links.
Slettet bruger
Slettet bruger
Opret
Preview
