25. december 2005 - 22:47Der er
38 kommentarer og 2 løsninger
Start med Iptables
Hej jeg har lige nogle spørgsmål vedr. IPtables.
Har kigget en del af de eksisterende spørgsmål her på siden igennem, og har også kigget på www.debianguiden.dk men har ikke kunne finde svar på mit nok, noget simple spørgsmål.
Nå nogen refere til deres script står der /bin/bash, hos andre står der /bin/sh og andre /bin/iptables
Hvor er placeringen til der hvor man skal skrive scriptet, og starter det automatisk op med serveren?
IPtables er et stort emneområde som kræver lidt at sætte sig ind i, men som kan give dig meget.
Du kan konfigurere det således at dit script med dine firewall regler køres ved start, men du kan også bare skrive det som en tekst fil og så exekvere det og dermed iværksætte dine firewall regler. hvis det er et shell script så hedder filer .sh til efternavn og du referere til bin/sh skriver du som et bash script er det bin/bash du bruger. Det er to forskellige scriptsprog og du kan skrive dit firewall script i begge.
Start med at give kommandoen:
iptables -L så kan du si din "running config" altså de regler derer i brug lige nu.
Jeg har lavet en stor certificeringsopgave til min GCFW certificering, hvor jeg bl.a. brugte IPtables. der er en forklaring du måsle kan bruge, og orker du at læse hele opgaven, så kan du også se hvorfor reglerne er som de er. jeg finder lige et link
Nu har jeg læst fra side 26-37 som jeg går udfra er det du hentyder til? Du beskriver reglerne rigtig godt, og der er helt sikkert meget jeg kan bruge, men du fortæller ikke (så vidt jeg kan se) noget om Iptables starter op sammen med systemet (debian) og hvor konfigurationsfilen (der hvor man skriver scriptet) ligger?
Firewallen en en del af kernlen på dit system, så har du ikke selv rekombileret kernlen (og der har du sandsyneligvis ikke) så vil firewallen være der.
ved at køre kommandoen iptables -L (stort l) fra en terminal vil du kunne se hvilke regler derer kørt i implementeret fra standart (sandsyneligvis alt åbent)
Dit eget script kan du så skrive og placerer i din egen mappe, hvor du så står når du kører scriptet. hvis du navngiver dit script f.eks. firewall.sh skal du simpelthend skrive firewall.sh i en kommando linie for at køre scriptet
Okay det hjalp mig rigtig meget. Men hvor ligger det script som jeg så kører når jeg skriver iptables -L ?
Der er bare mange der placere det i /bin/bash og lign stier så?
Jeg skal når jeg starter serveren op, gå ind i min egen mappe og kører scriptet for at "aktivere" det?. Det starter ikke op sammen med styresystemet?
Kan man bruge den her til at lave et script http://iptables-script.dk/ , eller vil jeg få et bedre script hvis jeg stykker noget sammen fra det kompendie duhar givet mig?
Jeg kan ikke huske om der faktisk ligger et script som køres (det gør der vist og jeg prøver at finde det til dig på tirsdag når jeg sidder foran min egen firewall) iptables -L giver dig ikke scriptet, men hvad firewallen har kørende af regler, altså de faktiske regler som firewallen har opfattet og følger.
Du kan finde flere færdige scripts og script generatore ude på nettet, og hvad du bruger kommer lidt an på formålet. Hvis du bare skal have en firewall kørende der giver fornuftig sikkerhed, så kan du sagtens bruge en script generator eller et færdigt script. Hvis du derimod selv vil kære at lave den slags, så skriv det selv og du vil sikkert kunne få noget ud af denne artikel
vend bare tilbage hvis du har mere, jeg skal selv til at køre en linuxfirewall op efter ikke at have rodet med det i næsten et år. Lige i øjeblikket arbejder jeg på at hardene maskinen. Jeg tager også udgangspunkt i nyeste debian
Jeg har lige læst din artikel, havde læst den før, men det tager jo ikke skade at få opfrisket det igen. Gør du også brug af at det kun er bestemte ip adresser der kan tilgå bestemte services i den pdf fil du sendte til mig?
Jeg er ikke så meget inde i at hadene min debian, men det må jeg så også lige læse lidt op på. Ville du råde mig til at køre med en Netfilter ovenpå?
En firewall bør altid hardnes, et stort emne som jeg erved atsætte mig ind i, Linux først og bagefter alle mine windows servere. og netfilter er jo firewallen så ja det er den der håndterer reglerne.
Hvis du har linux servere inde bag din firewall, så kan man ogerveje at konfigurere netfilter på dem også, her skal man så overveje nøjø hvad der filtreres og ikke sætte firewallen for kraftigt op. Jeg har software firewalls kørende på alle klienter som standard
IPtables er stateful inspection hvis du installerer de nødvendige moduler, især FTP er en udfordring, men det klare ftp modulerne, du kan se hvordan det gøres i min opgave
Okay, har du nogle guides til hvordan den jeg hardnere den?
Jeg har Linux servere inde bag firewallen, 3 af salgsen, hvor de alle sammen kører uden X og med den nyeste debian. Er det det samme når du siger at jeg kan overveje at konfigurere netfilter på dem som hvis man sagde at man kunne overveje at konfigurere iptables på dem?
Hvilke moduler skal jeg da installere for at få den til at være en stateful inspection firewall?
Den server der skal kører firewall skal ikke lave andet end det.
Jeg er i gang med at kikke på hardeningen, jeg kikker bl.a. på Bastille scriptet, SELinux kernlen, og Tiger scriptet, men jeg er endnu ikke parat til at udtale mig om dem. jeg har tænkt mig at køre en røkke forsøg i løbet af de kommende uger. Hvilke moduler du skal installerer afhænger af hvad du vil kører,Du kan se hvilke jeg installerer i min opgave, bl.a. FTP og nat moduler. Simple protokoller køre stateful inspection som default
Du er, lige som mange andre ude i lidt begrebsforvirring
ipchains=iptables=netfilter hvor netfilter er det nyeste navn men rigtig mange kander den stadig for iptables. Det er det samme blot er navnet ændret i takt med nyere kernler
Okay jeg vender tilbage med det script jeg er igang med at lave udfra din pdf fil. Så må du lige se hvordan det ser ud. Jeg sortere VPN og DMZ fra da det skal stå på et lukket netværk.
Var jeg ikke klar over, så er det da mærkeligt at man bruger $IPTABLES og ikke $NETFILTER?
Så blev jeg færdig med det (tror jeg). Min opsætning er således:
Jeg har en dmz zone, med en webserver, mailserver og en ftp server. Jeg har et lan med alm. klienter på, som skal kunne tilgå serverne via ssh, og ellers surfe normalt på nettet, bruge mail (sende og modtage), messenger IRC osv. Mit dmz skal kunne tilgså fra wan via ssh, mail (sende og modtage), web og ftp.
Tror det var det hele. Der er nogle ting i scriptet jeg er lidt usikre på om jeg har brug for, men det ser således ud:
# Default policies, smid alle pakker $IPTBLES -P INPUT DROP #Smid alle pakker som har firewallen som destination $IPTABLES -P FORWARD DROP #Tillad ikke noget traffik gennem firewallen $IPTABLES -P OUTPUT DROP #Smid alle pakker som har firewallen som kilde
# Create chains for LOCAL packets destination firewall $IPTABLES -N local $IPTABLES-F local
# Create chains for packets from the internal NETWORK $IPTABLES -N lan $IPTABLES -F lan
# Create a chain for packets from the internet $IPTABLES -N wan $IPTABLES -F wan
# Create a chain for packets from the DMZ $IPTABLES -N dmz $IPTABLES -F dmz
#..................................................... # SETTING UP RULES FOR LOCAL INTERFACE # Ensuring that the firewall can communicate locally #..................................................... echo -n "Setting up LOCAL chain
# Allow all connections, if the interface is local $IPTABLES -A local-m state --state NEW ESTABLISHED RELATED -j ACCEPT
echo "LOCAL chain is up and running"
#.......................................... # SETTING UP RULES FOR INTERNAL INTERFACE #.......................................... echo -n "Setting up LAN chain"
# Setting up protect against IP-spoofing $IPTABLES -A lan -s $WAN_IP/32 -j DROP $IPTABLES -A lan -s $LO_IP/S -j DROP $IPTABLES -A lan -s $DMS_IP/32 -j DROP $IPTABLES -A lan -s $LAN_IP/32 -j DROP
# Accepting all other established traffic $IPTABLES -A lan -m state --state ESTABLISHED RELATED -j ACCEPT $IPTABLES -A lan -j LOG --log-prefix "FW-LOG LAN INTERFACE." $IPTABLES -A lan -j DROP
echo "Done"
#..................................... # SETTING UP RULES FOR WAN INTERFACE #.....................................
echo -n "Setting up WAN chain"
# Protect against IP-spoofing $IPTABLES -A wan -s $WAN_IP/32 -j DROP $IPTABLES -A wan -s $LAN_IP/32 -j DROP $IPTABLES -A wan -s $LO_IP/S -j DROP $IPTABLES -A wan -s $DMZ_IP/32 -j DROP
$IPTABLES -A wan -m state --state ESTABLISHED RELATED -j ACCEPT $IPTABLES -A wan -j LOG --log-prefix "FW-LOG WAN INTERFACE." $IPTABLES -A wan -j DROP
echo "Done"
#.................................... # SETTING UP RULES FOR DMZ INTERFACE #.................................... echo -n "Setting up DMZ chain "
#Protect against IP-spoofing $IPTABLES -A dmz -s $WAN_IP/32 -j DROP $IPTABLES -A dmz -s $LO_IP/8 -j DROP $IPTABLES -A dmz -s $DMZ_IP/32 -j DROP $IPTABLES -A dmz -s $LAN_IP/32 -j DROP
$IPTABLES -A dmz -m state --state ESTABLISHED RELATED -j ACCEPT $IPTABLES -A dmz -j LOG --log-prefix "FW-LOG DMZ ITERFACE." $IPTABLES -A dmz -j DROP
echo "Done "
# Port forwarding rules to the servers on the DMZ$IPTABLES -A FORWARD -i # Port forwarding from WAN interface port 25 to mailserver port 25 on DMZ # Allow this traffic from any on the internet $IPTABLES -t nat -A PREROUTING -i$ETH_WAN -p tcp -d $WAN_IP --dport 25 -jDNAT --to-destination $EXT_MAILSERVER:25 $IPTABLES -A forwardfromwantodmz -p tcp --destination $EXT_MAILSERVER --dport 25 -j ACCEPT
# Port forwarding from WAN interface tcp port 80 to web server port 80 on dmz # Allow this from any on the internet $IPTABLES -t nat -A PREROUTING -i$ETH_WAN -p tcp -d $WAN_IP --dport 80 -j DNAT --to-destination $EXT_WEBSERVER:80 $IPTABLES -A forwardfromwantodmz -p tcp --destination $EXT_WEBSERVER --dport 80 -j ACCEPT
# Port forwarding from WAN interface tcp port 22 to webserver and mailserver port 22 on DMZ # Allow this from any on the internet $IPTABLES -t nat -A PREROUTING -i$ETH_WAN -p tcp -d $WAN_IP --dport 22 -j DNAT --to-destination $EXT_WEBSERVER:22 $IPTABLES -A forwardfromwantodmz -p tcp --destination $EXT_WEBSERVER --dport 22 -j ACCEPT
#NAT from LAN to WAN $IPTABLES -t nat -A POSTROUTING -s $LAN_NET -o $ETH_WAN -j SNAT --to-source $WAN_IP # NAT from DMZ to WAN $IPTABLES -t nat -A POSTROUTING -s $DMZ_NET -o $ETH_WAN -j SNAT --to-source $WAN_IP
# Packets coming from DMZ to WAN $IPTABLES -A forwardfromdmztowan -p udp --source $INT_DNS --destination $EXT_DNS --dport 53 -j ACCEPT
# Allow the mail server to send mails outbound # Accept established and realted traffic, log and drop the rest $IPTABLES -A forwardfromdmztowam -m state --state ESTABLISHED RELATED -j ACCEPT $IPTABLES -A forwardfromdmztowan -j LOG --log-prefix "FW-LOG WANTOSERVERPORTFWD" $IPTABLES -A forwardfromdmztowan -j DROP
# Packets coming from WAN to DMZ # Rules allowing in traffic are placed directly below NAT'ing rules # Accept established and related traffic, log and drop the rest $IPTABLES -A forwardfromwantodmz -m state --state ESTABLISHED RELATED -j ACCEPT $IPTABLES -A forwardfromwantodmz -j LOG --log-prefix "FW-LOG WANTODMZPORTFWD." $IPTABLES -A forwardfromwantodmz -j DROP
# Packets coming from DMZ to LAN. # Accept established and realted traffic, log and drop the rest $IPTABLES -A forwardfromdmztolan -p tcp --source $EXT_MAILSERVER --destination $INT_MAILSERVER --dport 25 -j ACCEPT $IPTABLES -A forwardfromdmztolan -m state --state ESTABLISHED RELATED -j ACCEPT $IPTABLES -A forwardfromdmztolan -j LOG --log-prefix "FW-LOG DMZTOLAN STATEFULL." $IPTABLES -A forwardfromdmztolan -j DROP
# packets coming from LAN to DMZ # Allow the LAN users to access the webserver on the DMZ $IPTABLES -A forwardfromlantodmz -p tcp --source $LAN_NET --destination $EXT_WEBSERVER --dport 80 -j ACCEPT
# Packets coming from LAN to WAN # Allow the LAN users to access http, https, ftp mailserver osv. on the internet $IPTABLES -A forwardfromlantowan -p tcp --source $LAN_NET --dport 80 -j ACCEPT $IPTABLES -A forwardfromlantowan -p tcp --source $LAN_NET --dport 443 -j ACCEPT $IPTABLES -A forwardfromlantowan -p tcp --source $LAN_NET --dport 21 -j ACCEPT $IPTABLES -A forwardfromlantowan -p tcp --sourve $LAN_NET --dport 25 -j ACCEPT
# Packets coming from WAN to LAN # Accept established and related traffic, log and drop the rest. $IPTABLES -A forwardfromwantolan -m state --state ESTABLISHED RELATED -j ACCEPT $IPTABLES -A forwardfromwantolan -j LOG --log-prefix "FW-LOG WANTOLAN PORTFWD." $IPTABLES -A forwardfromwantolan -j DROP
#........................ # ACTIVATE ALL CHAINS #........................
# Activation of chains $IPTABLES -A INPUT -i $ETH_LAN-j lan $IPTABLES -A INPUT -i $ETH_WAN-j wan $IPTABLES -A INPUT -i $ETH_DMZ-j dmz $IPTABLES -A FORWARD -i $ETH_WAN -o $ETH_DMZ-j forwardfromwantodmz $IPTABLES -A FORWARD -i $ETH_WAN -o $ETH_LAN-j forwardfromwantolan $IPTABLES -A FORWARD -i $ETH_DMZ -o $ETH_LAN-j forwardfromdmztolan $IPTABLES -A FORWARD -i $ETH_DMZ -o $ETH_WAN-j forwardfromdmztowan $IPTABLES -A FORWARD -i $ETH_LAN -o $ETH_DMZ-j forwardfromlantodmz $IPTABLES -A FORWARD -i $ETH_LAN -o $ETH_WAN-j forwardfromlantowan
Jeg er ret overbevist om at "stateful inspection" er et varemærke registreret af Checkpoint. I forbindelse med Netfilter kaldes det connection tracking.
Angående forskellen på /bin/bash og /bin/sh så er det eet fedt. Et firewall script er en række shell kommandoer samlet i en eksekverbar tekstfil. De bruger så ofte, men ikke nødvendigvis, kommandoshells mulighed for at håndtere funktioner, variable, flow control osv. I linux er standard shell /bin/bash og dette er en binær eksekverbar fil. Det er et program med andre ord. I Linux FHS mener jeg bestemt der står at /bin/sh skal være et symlink til /bin/bash for bagudkompatibilitet. Historisk var /bin/sh der hvor bourne shell var placeret i UNIX. Sagt på en anden måde: I linux skal du ikke bekymre dig om forskellem på bash og sh med mindre du laver din egen linux distribution.
Forvir heller ikke terminologien: Netfilter = Den kernel level firewall som er indbygget i Linux kernel iptables = det "userland" utility som benytter til at konfigurere netfilter. Altså, firewall'en hedder netfilter, iptables er et redskab. I kernel 2.2 serien hed redskabet ipchains.
"ipchains=iptables=netfilter hvor netfilter er det nyeste navn men rigtig mange kander den stadig for iptables. Det er det samme blot er navnet ændret i takt med nyere kernler" - Det er bare flat out Wrong.
- Det er bare flat out Wrong.>Det er hjelt korrekt at det dybest set ikke er helt rigtigt, men det er en ganske forståelig måde at forklare tingende på over for folk der ikke lige er inde i terminologien og ikke arbejder med det til dagligt. så flat out Wrong kan altså sagtens blive til now I get it i den virkelige verden
Okay nu har je fået netfilter/iptables på plads (tror jeg).
Hvordan ser mit script så ud, er der nogen fejl i det, eller vil det godt kunne bruges (selvfølgelig skal navnet på serverene og netkortene lige udskiftes, men ellers).
den letteste måde attese på er at køre scriptet. Det vil så fortælle dig hvor skrivefejl og stavebøffer findes. bagefter køre u iptables -L der så fortæller dig hvordan firewallen opfater scriptets regler. Til sidst kontrollerer man så at brugene kan det de skal og at de ikke kan det de ikke må
Okay det vil jeg prøve så, vender du tilbage til denne tråd når du har mere om at hardene en debian/linux maskine, eller vil du have min mail/messenger?
"ipchains=iptables=netfilter" Dette blir vel om lag som å skrive "dag=nat=solen skinner". Blir man noe klokere av det ? Selve hovedpoenget er jo at ipchains hører til Linux 2.2.x kernel og iptables tilhører 2.4.x og 2.6.x kernel og at virkemåten er omlag som dag og nat, altså ganske motsatt og forholdsvis helt ulik.
Når det gjelder "statefull inspection" mon det ikke var slik som strych9 skriver over. I dag så selger jo "alle" satefull inspection firewalls. Det er jo nesten umulig å finne noen som ikke er det.
Når det gjelder det scriptet som står over så har det en hovedstruktur og en oppbygning som kan fungere, men det har en del detaljer som gjør at det allikevell ikke kan fungere. Hovedstrukturen har også en slags eleganse og "finesse" ved seg synes jeg. Mon ikke dette er en omarbeidet utgave at et annet script som tidligere har fungert ? (Link til originalen ??)
Når det gjelder detaljer som kan ses med et halvt øye klokken 04:00 om natten:
1. "$IPTABLES -t filter -F" Her blir vel $IPTABLES vel faktisk en tekst streng uten definert innhold. Tekststrengen står ikke definert noe sted. Den blir følgelig tom.
2. "rmmod ip_conntrack_ftp" Her står det da vel faktisk at den skal remove kernelmodulen som har med ftp gjennom nat å gjøre. Mon det skulle stått insmod i stedet ?
3. $IPTABLES -t -FPOSTROUTING $IPTABLES -tnat -FPREROUTING Her må det settes et opphold etter -F, og tekststrengen må forandres for eksempel slik: iptables -t nat -F PREROUTING
4. Her brukes en serie med teksstrengvariabler som ikke er gitt verdi noe sted. De blir da uten mening:
$IPTABLES -A lan -s $WAN_IP/32 -j DROP $IPTABLES -A lan -s $LO_IP/S -j DROP $IPTABLES -A lan -s $DMS_IP/32 -j DROP $IPTABLES -A lan -s $LAN_IP/32 -j DROP
"$LAN_IP" Denne er for eksempel ikke definert til å bety noe.
Skriptet over fungerer nok ikke og det er en forholdsvis omfattende jobb å debugge det. (Men hovedstruktur ser med et halvt øye ut til å være rett.)
.... Nå forstår jeg hvor orginalen kommer fra, det er jo fra sertifiseringsoppgaven i linken nesten helt øverst !!
Den største og mest synlige feil i scriptet over kontra sertifiseringsoppgaven, det er at variabeldefinisjonene er utelatt. Se helt øverst på side 74 i sertifiseringsoppgaven.
Ellers så inneholder jo faktisk sertifiseringsoppgaven faktisk disse setningene:
Ut fra det som jeg har trodd helt fram til dette øyeblikk så skulle disse setningene ta vekk helt nødvendige nødvendige kernel moduler slik at firewall ikke skulle kunne oppgaven, med mindre at de aktuelle modulene ligger kompilert inn statisk slik at rmmod kommandoen for å fjerne den eventuelt ikke fungerer. (????)
Så skete der lig pludselig en del;) Vil det sige at jeg roligt kan fjerne de her linjer uden at det vil have nogen betydning? rmmod ip_conntrack_ftp rmmod ip_nat_ftp rmmod ipt_state rmmod iptable_nat rmmod ip_conntrack
Og kan det bedre betale sig for mig at tilpasse det script du henviser til langbein end det kan betale sig at begynde at fejlfinde på mit eget?
secusr: Hvor der står "rmmod" ligenu, retter du det til enten "modprobe" eller "insmod". og så sæt den her linje helt oppe i toppen under #!/bin/bash iptables=iptables Det erklærer en variabel som efterfølgende kaldes $iptables, eller hvis man ikke vil sjuske: ${iptables} og indholdet af variablen er "iptables". - Det kan jo være godt nok at gøre det på denne måde hvis man af en eller anden årsag langt langt ude i hampen enten ændrer navnet på sin iptables binary, eller hvis man regner med at iptables kommer til at skifte navn i de næste 2-3 år (det gør den ikke).
"Og kan det bedre betale sig for mig at tilpasse det script du henviser til langbein end det kan betale sig at begynde at fejlfinde på mit eget?"
Den siste (nederste) utgaven av scriptet som linken peker til skal kjøre umiddelbart, slik at det i prinsipp bare skal behøves en copy/paste.
Det går da ellers ganske hurtig å teste ut begge varianter.
Det skulle vært interessant og bra om det scriptet som står over i denne tråden også ble debugget, slik at vi kunne få postet en ferdig variant av dette scriptet også. Tenkte faktisk på å gjøre det selv, men problem: Har for tiden ingen 3 port Linux boks kjørende, slik at en testing bare blir sånn delvis.
Hvis du kjører testingen av scriptoppsettet over og legger ut scriptrevisjonene med feilmeldinger her, så kan vi vel forsøke å hjelpe til.
Okay, men synes også det ville være sjovere hvis jeg kunne få det her til at virke. Så ville jeg forhåbentlig også lære lidt af detm Jeg skal snartest muligt sætte en maskine op så jeg kan teste det, men har lidt travlt for tiden så det bliver nok ikke før til næste år:D
"men synes også det ville være sjovere hvis jeg kunne få det her til at virke."
Det synes nemlig jeg også, og jeg synes også dette er den rette innstillingen.
"Så ville jeg forhåbentlig også lære lidt af det" :-) Nemlig !
For mitt eget vedkommede så vil jeg si det slik at man med tiden får kanskje litt fikse ideer for hvordan ting skal være og hvordan ting skal fungere. For eksempel så bruker jeg selv alltid en slags "minimalistisk stil" der alle ting er redusert ned "til et minimum men dog med de ønskede funksjoner".
Grunnstrukturen til scriptet over er annerledes enn det som jeg personlig vanligvis benytter meg av, men den har samtidig veldig mange bra og interessante/spennende sider ved seg.
Forslag: Vi bestemmer her og nu at det scriptet som står over skal komme til å fungere. Videre så lager vi også en analyse/forklaring av hvordan det fungerer, hvilke funksjoner som blir ivaretatt og på hvilken måte, vurdering av eventuelt svake sider, angivelse av forbedringspotensmuligheter, osv.
secusr, tar du deg av testingen så kan vi forsøke å kjøre diskusjonen rundt det hele i denne tråden. (Eller skulle vi opprette en ny (?), den er jo faktisk lukket.)
Håper at strych9, bufferzone og flest mulig blir med på en diskusjon "til sakens opplysning".
Jeg kan godt teste på scriptet, men der er nok andre der er mere inde i det end mig, så det ville da være lækkert hvis vi var flere om at teste det. Jeg ved at bufferzone vist nok har et testcenter, men det kræver jo at han er interesseret i udviklingen?
Skal vi oprette en ny tråd eller skal vi blive i den her?
Jer er klart med, min test installation er dog først klar i løbet af uge 1, jeg er ved at teste forskellige hardening scripts og tiltag (f.eks. bastille, tiger og SELinux) på en debian Sarge
Det passer også mig fint bufferzone, der er jeg også først klar. Jeg kunne godt tænke mig at se hvad du fandt frem til med de der hardening scripts. Det ville være ret spændende. Og jeg tester også på debian sarge.
Den som skal lære noe bør nok jobbe litt selv også.
Å teste scriptet behøver ikke å bety noe annet enn å lage en copy paste av det som står her, eksekvere og så legge ut de feilmeldingene som kommer.
Håper at det som kommer ut av det er at scriptet over faktisk kommer til å fungere (med eventuelle tillegg og forbedringer + forklaringer) og at det fungerende og uttestede sluttresultatet blir postet her.
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.