14. oktober 2002 - 14:01Der er
83 kommentarer og 2 løsninger
problem med iptables firewall ?
Hejsa Jeg har lavet et lille firewall script som er mixet sammen af mange artikler samt en masse guf her fra andres spms meen jeg har et mega problem jeg lukker alt fra starten, men når jeg så åbner for udvalgte porte som feks http, ftp, pop3 o.s.v så hænger disse porte utroligt længe så det gør at det tager ca en halv time før jeg kommer igennem på pop3 og ftp når at disconecte inden jeg overhovedet kommer igennem, og det kan jo ikke være rigtigt
# # Configuration-stuff # GREP=/bin/grep SED=/bin/sed LANIF=eth1 LANIP="192.168.1.1" # The interface connected to your LAN WANIF=eth0 # The interface connected to the Internet WANIP=`/sbin/ip addr | grep ".*inet" | awk '{print $2}' | tail -n 2 | head -n 1 | cut -d '/' -f 1` # The IP of your WANIF if it's static otherwise # leave blank
# # Define the programs # IPTABLES="/sbin/iptables" SYSCTL="/sbin/sysctl"
# #opseatning af selve firewallen # $IPTABLES -P INPUT DROP $IPTABLES -P FORWARD DROP $IPTABLES -P OUTPUT ACCEPT $IPTABLES -F INPUT $IPTABLES -F FORWARD $IPTABLES -F OUTPUT
# #Lav ny chain til INPUT og OUTPUT # $IPTABLES -N block $IPTABLES -F block
# #Tillad trafik paa allerede oprettede forbindelser # #$IPTABLES -A block -m state --state ESTABLISHED, RELATED -j ACCEPT $IPTABLES --table nat --append POSTROUTING --out-interface $WANIF -j MASQUERADE $IPTABLES --append FORWARD --in-interface $LANIF -j ACCEPT $IPTABLES --append FORWARD --in-interface $WANIF --match state --state ESTABLISHED,RELATED -j ACCEPT
# #Tillad nye forbindelser hvis de kommer inde fra # #$IPTABLES -A block -m state --state NEW -i ! ppp0 -j ACCEPT
# #Tillad trafik paa udvalgte porte # #$IPTABLES -A block -m state --protocol tcp --state NEW --destination-port 80 -j ACCEPT #$IPTABlES -A block -m state --protocol tcp --state NEW --destination-port 21 -j ACCEPT #$IPTABLES -A block -m state --protocol tcp --state NEW --destination-port 22 -j ACCEPT $IPTABLES -A block -p tcp -d $WANIP --dport 80 -j ACCEPT $IPTABLES -A blick -p tcp -d $WANIP --dport 22 -j ACCEPT $IPTABLES -A block -p tcp -d $WANIP --dport 21 -j ACCEPT # #Flytte udvalgte porte til anden maskine # #$IPTABLES -t nat -A PREROUTING -i $WANIF -p tcp -d $WANIP --dport 6112 -j DNAT --to-destination 192.168.1.2 #$IPTABLES -t nat -A PREROUTING -i $WANIF -p udp -d $WANIP --dport 6112 -j DNAT --to-destination 192.168.1.2 #$IPTABLES -t nat -A PREROUTING -i $WANIF -p tcp -d $WANIP --dport 4661 -j DNAT --to-destination 192.168.1.2 #$IPTABLES -t nat -A PREROUTING -i $WANIF -p tcp -d $WANIP --dport 4662 -j DNAT --to-destination 192.168.1.2 #$IPTABLES -t nat -A PREROUTING -i $WANIF -p udp -d $WANIP --dport 4665 -j DNAT --to-destination 192.168.1.2
# #Block alt andet # #$IPTABLES -A block -j LOG
# #Aktiver den nye chain # $IPTABLES -A INPUT -j block $IPTABLES -A FORWARD -j block
sorry at det er mega rodet meen jeg har forsøgt mig frem mange gange efterhånden er der nogen der ved hvad der skal rettes på i åbningen af portene ?? forwarden virker som den skal
#$IPTABLES -A block -m state --protocol tcp --state NEW --destination-port 80 -j ACCEPT #$IPTABlES -A block -m state --protocol tcp --state NEW --destination-port 21 -j ACCEPT #$IPTABLES -A block -m state --protocol tcp --state NEW --destination-port 22 -j ACCEPT $IPTABLES -A block -p tcp -d $WANIP --dport 80 -j ACCEPT $IPTABLES -A blick -p tcp -d $WANIP --dport 22 -j ACCEPT $IPTABLES -A block -p tcp -d $WANIP --dport 21 -j ACCEPT
som sagt når jeg / andre prøver at kontakte min ftp server komemr de slet ikke ind da den når at diske inden
hvis man prøver at hendte post via pop3 får man beskeden med at der er gået 60 sec og om man vil vendte yderligere 60 sec. Denne besked får man et halvt hundrede gange og så kommer man ind.
yderligere mere hvis jeg efter at have aktiveret dette script skriver # iptables -L så går der også utrolig langtid før den kører alle de åbne porte ud og når det er sket kommer resten frem med lynets hastighed
sååå der må være en konflikt i den måde portene bliver åbnet på
hmm jamen meningen er jo at det skal beskytte mod hack :-) alt i scriptet virker som det skal så det ville næsten være dumt at omskrive alt Jeg skal bare finde en ordentlig måde at åbne prote på efter jeg har blokket dem som sker i starten. det er det eneste der ikke virker i det
Her er mit bud på et script der virker hos dig.. brug det hvis du vil :o] Jeg synes det var nemmere end at forsøge at forstå dit script.
# eth0=WAN # eth1=LAN # lan= 192.168.0.1
modprobe ip_conntrack_ftp modprobe ip_nat_ftp
iptables -t nat -A POSTROUTING -s 192.168.0.1/24 -j MASQUERADE iptables -P INPUT DROP iptables -P OUTPUT DROP iptables -P FORWARD DROP iptables -A INPUT -j ACCEPT -i lo iptables -A INPUT -j ACCEPT -m state --state ESTABLISHED,RELATED
iptables -A INPUT -j ACCEPT -p tcp --dport 21 iptables -A INPUT -j ACCEPT -p tcp --dport 25 iptables -A INPUT -j ACCEPT -p tcp --dport 110 iptables -A INPUT -j ACCEPT -p tcp --dport http iptables -A FORWARD -j ACCEPT -p tcp --dport 80 iptables -A FORWARD -j ACCEPT -p tcp --dport 21 iptables -A FORWARD -j ACCEPT -p tcp --dport 25 iptables -A FORWARD -j ACCEPT -p tcp --dport 110
hmm det ligner noget du har bikset sammen til dig selv ?? har man ret ?? :-) nå men ud over det jeg skal da nok prøve at rette det til og se om jeg kan få det igennem
:-) okey tænkte nu bare på portene, det stemmer bestemt ikke overens med min opsætning, det var derfor det lignede det var taget direkte fra dit eget men jeg beder jo heller ikke om en ferdig læsning blot lidt hjælp til at få åbningen til at virke forresten hvad betyder disse 2 linier ?
modprobe ip_conntrack_ftp modprobe ip_nat_ftp dem har jeg vist ikke set før
nåååeee ja.. jeg kiggede ikke rigtigt på hvilke porte du skulle bruge.. Det kan du relativt nemt ændre selv i dette scripts.
ip_conntrack_ftp & ip_[..] Er for at tillade passive connections til FTP.. sådan så conntrack (connection tracking) også "samler" port 20 op i en ftp session.. Sådan noget i den retning i alle tilfælde.. Men det tillader f.eks. ikke DCC send, som kender fra Irc.. Til dette skal irc modulerne loades hvis du skal bruge det.
Det afsluttes/aktiveres med: iptables -A INPUT -p TCP -m state --state RELATED -j ACCEPT
p.s.. Du må ikke spørge om så meget.. Tænk hvis jeg ikke ved det :o]
hmm sorry Dank men det hjalp hellre ikke meget på problemet Jeg rettede det til så det passede med mine porte og fyrede den af, men mine porte hænger stadig utrolig længe
Skwat> nej du har ret det var en fejl (godt set) meen det var heller ikke nok til at få det til at virke
dank -> Scriptet ditt over inneholder faktisk et par grunnleggende logiske feil. Feilene er imidlertid slik at den ene feil slår i hjel den annen slik at scriptet utad tilsynelatende fungerer ok. Vil du vite om dem ?
Ellers så bør det første prinsipp for firewall scripts etter mitt syn være at de er laget så enkle og overskuelige at det er lett å lese ut de funksjonene som finnes i dem. Dette prinsipp følger du og derfor så er det også lett å se feilen(e) med et halvt øye. ;-)
hanibal: helt ærlig - er ikke helt sikker på om jeg har lest eller forstått spørsmålet ditt rett, men når ting "henger" så hender det at det har med dns timeout problematikk å gjøre. Når man setter opp en tilordning i /etc/hosts filen så kan man til tider rette opp dette. Det er i hvert fall fort gjort å prøve ut, og ut fra erfaring så kan det hjelpe i mange situasjoner. Har imidlertid ingen full forståelse av hva det er du har satt opp eller hva det er som henger, så det kan være at mitt tips ikke har relevans.
Du kan roligt tilføje prerouting linier igen til dette script.. jeg er næsten 100% sikker på det vil virke..
Langbein: Ja tak.. Jeg har en god idé om hvad du tænker på, men vil gerne høre det fordi jeg ved du har studeret iptables temmeligt meget - mere end mig :o)
Og årsagen til at jeg postede et nyt script fremfor at debugge det eksisterende var at jeg synes simpelthen det originale script var en smule for uoverskueligt - ( ikke ment som en fornærmelse Haniball - håber ikke det bliver opfattet sådan..)
dank> nej det var bestemt ikke opfattet sådan. Jeg kan godt se hvad du mener, men som sagt der er også testet meget med det, og derfor stod der også en masse med # forand meen som sagt for også at gøre det lettere for jer som gør et forsøg på at hjælpe syntes jeg det bare var lettere at fjerne den del der bare skulle routes. Det har jeg jo styr på, det er jo det med at få portene åbne ordentligt jeg ikke kan få til at fungere ordentligt
ok jeg blev bare lidt forvirret over dit indlæg fra 11:07:47... betød det at det virkede eller ikke gjorde.. altså åbningen af portene med det script... Hjælp mig lidt her.... tabte lige tråden :o]
Er 100 % enig med dank om at det viktigste for firewall scripts og all annen programmering også, det er enkelhet, struktur og oversiktelighet.
En feil som går igjen i ganske mange iptables firewall scripts som man kan finne på webben det er at scriptene er laget ut fra en forutsetning om at prinsippene for datatransport gjennom 2.4 kernel er lik prinsippene for datatransport gjennom 2.2 kernel. Med andre ord man laget iptables script ut fra de samme prinsipper som man benyttet for ipchains script. For eksempel så har man også utrolig nok videreført denne feilen i følgende bok: Red Hat Linux Security and Optimization utgitt av Red Hat press i år 2002 i kapittlet om firewalls.
Tidligere (kernel 2.2) så var det slik at de to chains INPUT og FORWARD fungerte i serie etter hverandre slik at alle packets først passerte inn gjennom innput chain. Der etter så bel noen packets ut fra nærmere kriteria sendt videre til FORWARD chain.
Ved overgangen til kernel 2.4 så programmerte Rusty Russel en ny firewall / forwarding modul der datatransporten gjennom de to chains INPUT og FORWARD var skilt helt ad fra hverandre.
Fra kernel 2.4 så filtrerer INPUT og FORWARD chains pakker uavhengig av hverandre. Det vil si at de rules som man formulerer for INPUT chains vil være uten betydning for de datapakker som routes videre til LAN. INPUT chains filtrerer bare trafikken til de lokale prosessene på selve router maskinen. Dersom det dreier seg om en ren firewall/router maskin så bør følgende regelsett for INPUT chain være tilstrekkelig:
iptables -P INPUT DROP
Med andre ord: Ingen skal kunne logge seg inn på firewall maskinen annet enn fra firewall console.
De pakkene som skal til eller fra LAN transporteres og filtreres gjennom FORWARD chain uten først å passere gjennom INPUT chain. Regelsettet for INNPUT og FORWARD chain er med andre ord to helt uavhengige og separate regelsett fra og med kernel 2.4.
Prerouting setningen trer vel faktisk i kraft før INPUT chain. Det vil si at prerouting sender pakkene av gårde gjennom FORWARD chain før de rekker fram til INPUT chain. Dette vil si at den feilaktige åpning til lokale prosesser på firewall maskin allikevell ikke vil skje.
Derfor så fungerer scriptet slik som det skal utad til tross for noen INPUT rules som ikke skulle ha vert der.
Ellers så ser jeg at scriptet mangler de tingene som har med flushing or resetting av rules å gjøre. Bør vel stå i starten av scriptet.
Når det gjelder det scriptet som hanibal har laget til slutt:
iptables -A INPUT -j ACCEPT -p tcp --dport 80
Her forutsetter du at web server kjører på selve firewall maskinen er det rett ??
Disse bør virke sammen på en ok måte slik som du har satt dem opp:
(A) iptables -t nat -A POSTROUTING -s 192.168.0.1/24 -j MASQUERADE og (B) iptables -A FORWARD -m state --state ESTABLISHED,RELATED -j ACCEPT
Med andre ord:
Set opp nat deling av internett forbindelse (Setning A) og sørg for at bare forbindelse initiert innefra LAN og ut har forbindelse (Setning B). Dette fungerer korrekt, gjør det ikke ? (Typisk par av NAT og FORWARD setning som må fungere i sammenheng med hverandre for å gi noen funksjon med mindre FORWARD policy er satt til ACCEPT.)
input= Kun pakker til selve routeren forward kun pakker WAN <> LAN men uden om routeren ouput = fra routeren til WAN/LAN
Er dette forstået korrekt?
Så mit script skulle altså se sådan ud:
# eth0=WAN # eth1=LAN # lan= 192.168.0.1
+++ Flushing regler her... <--------
modprobe ip_conntrack_ftp modprobe ip_nat_ftp
iptables -t nat -A POSTROUTING -s 192.168.0.1/24 -j MASQUERADE iptables -P INPUT DROP iptables -P OUTPUT DROP iptables -P FORWARD DROP
iptables -A FORWARD -j ACCEPT -p tcp --dport 80
iptables -A OUTPUT -j ACCEPT
iptables -A FORWARD -j ACCEPT -i eth1 -s 192.168.0.1/24 iptables -t nat -A PREROUTING -i eth0 -p tcp --dport 80 -j DNAT --to 192.168.0.163:80 iptables -A FORWARD -m state --state ESTABLISHED,RELATED -j ACCEPT
-------
Er dette forstået korrekt? D
og mener jeg at der stadig skal være:
iptables -A INPUT -j ACCEPT -m state --state ESTABLISHED,RELATED
For at connection tracking (passive_ftp) fungerer som det skal. Men det kan muligvis undlades hvis FTP serveren ikke ligger på selve routeren og kan istedet erstattes af:
iptables -A FORWARD -m state --state ESTABLISHED,RELATED -j ACCEPT
Hvis FTP serveren ligger på en LAN PC.
Hvis disse teorier/eksempler er korrekte.. Så har jeg forstået iptables 2x bedre end førhen. Tusind tak for denne forklaring.
Dette er IKKE i samsvar med det som man for eksempel kan lese i Robert L. Ziegler: LInux Firewalls 2'nd ed.
Min enkle begrunnelse for dette er at lan kjører en ip nummerserie som ikke er routbar over internett. Altså finnes det bare en rotbar ip adresse og det er den eksterne ip. Så lenge det ikke finnes noen nat chain som sender en bestemt port inn på lan så kan denne ip pakken med det aktuelle portummer helleri ikke komme inn på lan. Derfor følger indirekte en firewall effekt ved bruk av nat ! (Enig !!?)
Har så langt ikke mottatt noen god argumentasjon mot dette prinsippet og jeg bruker det selv. (I hvert fall inn til vidre :-) )
Har grunnet mye på dette med å sette FORWARD til ACCEPT, om det er sikkert nok. Etter som jeg delvis har funnet på denne løsningen selv så føler jeg meg jo i utgangspunktet litt usikker på dette.
Prinsippet bør vel være at dersom man benytter en intern ikke routbar nummerserie inne på lan, så bør det være rimelig sikkert å la være å filtrere inngående trafikk ved hjelp av FORWARD chain. Jeg ser ellers for eksempel at CISCO 677 routeren er laget slik at den utnytter dette prinsippet. Den filtrerer ikke men ved å la være å forwarde en del porter til lan så oppnås indirekte en filtrering allikevell ved at den forholder seg passivt til en del portnummer der det altså ikke skjer noen komunikasjon.
FORWARD chain i Linux 2.4 forwarder ellers ikke på noen måte som helst. Den bare filtrerer. Står FORWARD policy til ACCEPT så behøves ingen åpninger i FORWARD filteret.
All forwarding inaretas gjennom DNAT og SNAT setninger, med eller uten et tillegg av filtrering via FORWARD setninger (som altså ikke kan forwarde.)
Velger man eventuelt å sette FORWARD policy til DROP så må man for hver DNAT og og for SNAT setningen sørge for at det finnes de nødvendige FORWARD setninger som gir åpning for de aktuelle porter i den i utgangspunktet lukkede FORWARD filtering chain.
For enkelte protokoller og services slik som for eksempel ftp og dns (tror jeg) så kan det være en del tricky å sette opp FORWARD rules. Derfor så vil det uansett være en god ide å sette opp firewall først med FORWARD filtering chain til DROP og så event i neste omgang til ACCEPT.
Hvis det interne lan benytter en ipadresse serie som er globalt routbar så har man ikke noe valg. Da må man ha FORWARD rules.
Jeg er veldig nyskjerrig på om det er noen som allikevell kjenner til prinsipper for å komme inn på et lan med en intern i prinsipp ikke routbar nummerserie.
okey nu må jeg spørge Er dette drevet over i noget helt andet eller hvad ?
som sagt mine PREROUTING's fejler intet de virker perfekt, men de porte som skal åbnes på selvsammen computer som forewallen, det er dem som ikke virker.
Jeg ser at langbein's sidste eks kun indeholdte prerouting, så det er derfor jeg spørger
Hele diskusjonen over kan vel kort oppsummeres som følger:
1. Forwarding ports til LAN gjennom router "åpnes" i praksis ved hjelp av prerouting setninger hvis forwarding chain som default er satt til ACCEPT. Hvis ikke behøves også FORWARD rules.
2. Dersom det dreier seg om tilgang til de prosessene som kjører på selve Linux maskinen så kan du enten sette INPUT policy til ACCEPT. Det er det samme som å åpne for alle porter. Alternativt så setter du policy til DROP. Da må du i prinsipp åpne for hver port enkeltvis ved hjelp av setninger av denne typen:
iptables -A INPUT -p tcp --dport 80 -j ACCEPT
Å åpne det nødvendig antall "huller" til de lokale prosessene pleier normailt ikke å medføre noe problem. Hvis det dreier seg om en ren router så pleier man jo ikke å ha en slik åpning til lokale prosesser. For en "kombinert hjemmeserver" så kan vel dette være aktuelt.
Langbein: Jeg har konsulteret din teori med andre der ved "meget" om iptables og linux generalt..
Det viser sig at de har samme holdning som din. Dog med en undtagelse:
Output DROP bliver brugt mange steder af de mere "pro" linux folk. Dette skyldes at du på den måde kan kontrollere et attack.. F.eks. hvis en server på dit LAN er overtaget med noget DDOS.. Så kan man ved Output DROP forhindre serveren i at kontakte "moderserveren" - hvilket jo godt kan være en fordel.
(Medmindre serveren kontakter WAN via en af de tilladte porte selvfølgelig)
Dog siger alle jeg har snakket med, at man ligeså godt kan benytte 3xdrop - så er man på den sikre side.. Jeg skal ikke her redegøre for om jeg er enig i denne påstand.. Men det synes at være en gængse opfattelse blandt dem jeg har snakket med.
Haniball: Sorry hvis vi kom en smule off-topic i forhold til dit oprindelige spørgsmål. Men mon ikke disse informationer kan komme nogen til gang hvis de læser dette :o)
"Output DROP bliver brugt mange steder af de mere "pro" linux folk." Jo, kjenner til dette. Står blandt annet beskrevet i R.Ziegler sin Firewall bok, men til hjemmebruk ..
Men hva er 3xdrop ?? Hva er forresten DDOS ?
Det smarte med floppyfw er ellers at den har låst filsystem (Hvis man låser floppydisken) man kan ikke skrive til fil, og så har den null påloggingskontoer med unntak av root fra console. Ellers så kan den kjøre de samme firewallscripts som Red Hat og de andre. http://www.zelow.no/floppyfw/
iptables -P INPUT DROP iptables -P OUTPUT DROP iptables -P FORWARD DROP
Mht til FloppyFW så har jeg ingen erfaringer med denne.. Men jeg har opsat lignende systemer hos nogle erhvervskunder, bl.a. (www.coyotelinux.com & www.freesco.org) Begge systemer kører tilfredsstillende og stabilt og sikkert.Så det er uden tvivl en udemærket løsning.
Hvis dette kjører fint så kjør følgende kommandoer for å sjekke at firewall står åpen:
iptables -L
iptables -t nat -L
Når så firewall er konstantert å stå helt åpen, forsøk så å komme inn på de aktulle porter eller servises. Kommer du ikke inn så ligger feielen et annet sted enn i firewall.
Hvis feilen er konstantert å ligge i firewall, kjør så det nye firewall scriptet en gang til (det med firewall regler). Legg ut beskjed her hvilke porter eller services som ikke vil kjøre.
Jeg har lige testet scriptet.. samt flere af de kombinationer der har været nævnt i denne tråd.. De er testet i et setup med en iptables router samt 8 lan maskiner..
Langbein: Endnu et argument for at have "Forward DROP" er at en portscan udefra vil ikke kunne se porten (stealthed).. med Forward ACCEPT vil porten være Blocked - det vil sige at portscanningen vil afsløre porten men får ikke noget svar på den..
I et sikkert system gælder det om at sløre så meget som muligt for evetuelle hackers/intruders.
dank -> Det var godt at du fikk testet scriptet. Har diverse bugs her borte nå i forbindelse med helt andre ting, så fikk bare sjekket at syntaksen var ok, ikke noe mer enn det.
Når det gjelder dette:
"Endnu et argument for at have "Forward DROP" er at en portscan udefra vil ikke kunne se porten (stealthed).. med Forward ACCEPT vil porten være Blocked"
Nei, har du sjekket dette ? Mener da å være rimelig sikker på at det ikke fungerer slik. Dersom man kjører for eksempel web server på 192.168.0.1, 192.168.0.2 og 192.168.0.3 og så man da scanner den utvendige ip utenfra, så vil man vel ikke kunne se dette ?! Setter man op en DNAT til en av de interne serverne for eksempel 192.168.0.2 så vil denne være synlig ved en ekstern portscan fra det øyeblikk at dnat'en kjører. (Mener da å ha sjekket dette noen ganger ??) For at den interne web serveren skal være synlig eksternt så må man enten la forward policy stå til ACCEPT eller man må sette opp en enkelt forward regel eller de forward regler som behøves for å gi de nødvendige åpninger.
Det at man setter opp og gjør synlig en enkelt intern webserver vil vel ikke medføre at de andre også som ligger på andre adresser også blir synlige ?? (Eller finnes det spesielle måter å scanne på slik at de faktisk blir synlige de også ??)
Haniball -> Ditt spørsmål er under rubrikken "Red Hat". Da må det jo dreie seg om en Red Hat. For Red Hat 7.1/7.2/7.3 så forholder det seg at enkelte porter for eksempel porten for mail (var det ikke 25) er blokkert i Red Hat sitt standardoppsett. Porten(e) er blokkert men dette har ingen ting med firewall å gjøre. Firewall kan slippe gjennom pakkene, men pakkene blir blokkert videre innover i "systemet". (Dette kan være temmelig vanskelig å finne ut av og det er noe av det som jeg liker absolutt dårligst med Red Hat.)
Hvilken Red Hat versjon og hvilke porter dreier det seg om ??
nå men nu er der jo kommet ret mange spm's siden mit men vil da prøve at besvare bedst muligt.
Dank> Ja jeg kan også komme igennem, men på port 80 hænger den ca 30 sec hvor der så står udført i browseren og derefter kommer den så. at skulle tjekke email hønger den næsten uendeligt. og ftp hænger den så meget at ftp når at disconecte ved listing af alle filer så jeg kommer arldrig rigtigt ind.
Langbein> med iptables -L skrives alle chains ud og dem som skrives som ACCEPT kommer også og en portscanning viser også at porten er åben, men som sgt den er utrolig hurtig.
iptables -t nat -L viser også alle de PREROUTINGS som den skal, men det er jo ikke aktuelt i dette spm.
Jeg har prøvet alle RH 7.* og en ting jeg arldrig har prøvet er at port 25 skulle være lukket og det er den heller ikke her, fjerner jeg iptables --policy INPUT DROP virker port 25 som den skal, meeen som sagt port 25 er SMTP og den har jeg slet ikke afprøvet, meen mon ikke den teer sig som de andre ?
SMTP har pleid å være blokkert den ene vei men ikke den annen.
" Langbein> med iptables -L skrives alle chains ud og dem som skrives som ACCEPT kommer også og en portscanning viser også at porten er åben, men som sgt den er utrolig hurtig. "
Hvis den synes på portscanning så tyder vel det på at ikke bare firewall er åpen men også at prosessen bak firewall kan detektes. Den skulle med andre ord kjøre noenlunde ok.
Synes problemet ditt minner om en DNS sak. Hva om du taster http://<ip-nr> fra en ekstern klient henger den da også ?
Hvis ikke så dreier det seg vel om et dns problem.
Har du vært inne i /etc/hosts filen og sjekket om det er en sammenheng mellom logisk adresse (www.domene.dk) og ip nummer i denne filen ? Gå inn og sjekk om denne er redigert rett. (Her har det ofte ligget hos meg.)
i etc/hosts står der følgende 127.0.0.1 localhost.localdomain localhost
Det er ligemeget om jeg kontakter serveren på den ene eller anden måde så opstår denne langsomhed men som sagt sætter jeg den til iptables -p INPUT ACCEPT på dem alle i stedet for DROP så virker alt jo som det skal det er netop det som undrer mig meen hvad skal man ellers skrive i /wtc/hosts ??
For eksempel: 127.0.0.1 localhost.localdomain localhost 152.198.14.8 dittdomene.dk servernavn.dittdomene.dk
Har ikke noe å se etter her og nå og blir litt i tvil: Hva er det som skal stå på linje no 2 er det den lokale eller den globale ip adressen ? Tror det er den som er konfigurert til ditt wan kort.
Det ser for meg ut som om feilen ligger akkurat her. Maskinen pleier å henge et stykke tid dersom denne tilordningen mangler. (Husker heller ikke sikkert om det er nødvendig å skrive maskinnavn.domenenavn.dk eller om det holder med bare domenenavn.dk.
ok ok nu har jeg gjordt følgende i min /etc/hosts har jeg tilføjet følgende mit_gobale_ip mittdomene.dk
og min iptables ser nu sådan her ud.
#!/bin/bash
# # Configuration-stuff # GREP=/bin/grep SED=/bin/sed LANIF=eth1 # The interface connected to your LAN WANIF=eth0 # The interface connected to the Internet WANIP=`/sbin/ip addr | grep ".*inet" | awk '{print $2}' | tail -n 2 | head -n 1 | cut -d '/' -f 1` # The IP of your WANIF if it's static otherwise # leave blank
# # Define the programs # IPTABLES="/sbin/iptables" SYSCTL="/sbin/sysctl" $IPTABLES --policy INPUT DROP $IPTABLES --policy FORWARD DROP $IPTABLES --policy OUTPUT ACCEPT # # Flush all current chains in "filter" (default) and "nat" tables # modprobe ip_conntrack_ftp modprobe ip_nat_ftp $IPTABLES --flush $IPTABLES --table nat --flush
# # Delete all user-defined chains in "filter" (default) and "nat" tables # $IPTABLES --delete-chain $IPTABLES --table nat --delete-chain
a. indikasjonene ved iptable -L og iptable -t nat -L er "normal" da skal firewall være i orden. b. /etc/hosts I min fil så står oppføringen på denne måten: 152.198.14.8 server1.eksempeldomene.dk
c. Hva hvis du fra en utvendig klient lar være å bruke logisk navn (eksempeldomene.dk) og i stedet noe ala http://152.198.14.8 Henger den da også ?? (Tenker på dns problematikken.)
Hvis det fortsatt ikke kjører, skaff også 100 % sikker konklusjon for om det er input eller forward chain som får den til å henge. Forsøk vekselvis med bare input og pare forward satt til drop og sjekk hvilken chain det er som får den til å henge. Legg beskjed !
Hvis vi vet at problemet er relatert til firewall script og at et ferdig testkjørt script ikke kjører, bør det ikke da være noe bugs med selve kernel / iptables ??
Ja det kører på samme maskine som firewall gør men som sagt forward virker heller ikke hvis jeg sætter dem til DROP hvorefter jeg giver dem nat bagefter
det er ligesom om at så snart jeg laver drop så virker det hele af H.til
men hvis jeg bruger et firewall program som feks guarddog som er beskrevet på www.gnuskole.dk som også bruger mine iptables, så virker det som det skal, men jeg skulle jo gerne kunne lave det selv uden grafiske programmer
Tja, det kan se ut som om syntaksen i iptables ikke fungerer slik som den skal hvis jeg har forstått det du har skrevet rett. Sannsynligvis så finnes det en eller bakenforliggende grunn til dette. Det er vel tvilsomt om nye eller andre firewall script vil kunne endre på dette (!?) Det er ikke godt å si hva denne feilen kan ligge i .... men på den annen sisde .. er det mulig med en ssh pålogging her i fra ??
altså umidelbart tror jeg ikke på at der er noget galt med selve programmet "iptables" for som sagt installerer jeg forewall programmet guarddog som også bruger iptables til at sætte det hele op med og som også laver en drop på både INPUT og FORWARD ja så virker det alt sammen som det skal og det er også hurtigt, men som sagt vil jeg helst ikke benytte mig at det program da det kræver grafisk login og jeg vil helst ikke have dette installeret, jeg vil gerne lære det uden grafisk
dank jeg har prøvet dit link og lavet copy til en ny fil og prøvet at fyre den af på linux, meen den giver ikke andet end fejl
: command not found : No such file or directoryipv4/ip_forward : command not found : command not found modprobe: Can't locate module ip_nat_ftp modprobe: Can't locate module ip_conntrack_ftp : command not found iptables: No chain/target/match by that name iptables: No chain/target/match by that name iptables: No chain/target/match by that name iptables: No chain/target/match by that name : command not found iptables: Bad policy name iptables: Bad policy name iptables: Bad policy name : command not found iptables v1.2.5: Unknown arg `nat' Try `iptables -h' or 'iptables --help' for more information. iptables v1.2.5: Unknown arg `iptables' Try `iptables -h' or 'iptables --help' for more information. iptables v1.2.5: Unknown arg `iptables' Try `iptables -h' or 'iptables --help' for more information. : command not found ' specified.2.5: invalid TCP port/service `80 Try `iptables -h' or 'iptables --help' for more information. ' specified.2.5: invalid TCP port/service `21 Try `iptables -h' or 'iptables --help' for more information. ' specified.2.5: invalid TCP port/service `110 Try `iptables -h' or 'iptables --help' for more information. ' specified.2.5: invalid TCP port/service `25 Try `iptables -h' or 'iptables --help' for more information. ' specified.2.5: invalid TCP port/service `22 Try `iptables -h' or 'iptables --help' for more information. : command not found : command not found : No such file or directoryipv4/ip_forward
Betyder at disse ikke er kompileret med som modul i din kernel.. (hvilket måske ikke er så smart )
Jeg kender til mindst 6 forskellige der nu har benyttet script generatoren. Og den virker på alle deres maskiner. Dog har der været nogle forspørgelser på nogle specielle features som ikke lige var med. F.eks. at tillade conntections fra lan til router (ubegrænset) og nogle andre småting.. disse bliver rettet i scriptet i aften
Langbein: Jeg har lige tjekket min Hotmail. Jeg har fået en lang mail. Jeg svarer den iaften. Jeg har netop købt ny "hoved" PC som skal blive til min nye private workstation, men den giver mig en masse problemer fordi min nye raid controller ikke understøttes af linux. Så jeg kan være lidt lang tid om at svare mails disse dage :o)
okey nu har jeg endelig fået noget af det til at virke der er blot et problem mine andre computere skal jo også have lov til at komunikere med min dhcp server. Som det er nu, hvis jeg fyrer skriptet af så virker det mere eller mindre som det skal, men så går der lidt tid og vupti så er jeg slet ikke online på min windåse maskine, meen det er nok fordi den vil kontakte dhcp serveren for at få godkendelse på rettighederne igen hvad gør jeg med den ?
nå men det ser ud til at dette også er blevet rettet nu. Dank>> vil du afgive et svar også ? mit script er vist blevet en blanding af begges udtalelser så det må være rimeligt at i deler pointsne
"Men da har det vist seg at årsaken har ligget i firewall på windows maskinen " nixx der har jeg ingen firewall overhovedet. Fejlen lå i at der var nægted adgang så clienterne IKKE kunne få tildelt ip nummer fra dhcp serveren
Synes godt om
Ny brugerNybegynder
Din løsning...
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.
