iptables har jeg fået et andet sted fra som virker men her er det.
#!/bin/bash # firewall # # Starter, stopper og restarter firewall # # ---------------------------------------------------------------- # | ACCEPT/ lo interface | # v REDIRECT _______ | # --> C --> S --> ______ --> D --> ~~~~~~~~ -->|FORWARD|----> _______ --> # h a |INPUT | e {Routing } |Chain | |OUTPUT |ACCEPT # e n |Chain | m {Decision} |_______| --->|Chain | # c i |______| a ~~~~~~~~ | | ->|_______| # k t | s | | | | | # s y | q | v | | | # u | v e v DENY/ | | v # m | DENY/ r Local Process REJECT | | DENY/ # | v REJECT a | | | REJECT # | DENY d --------------------- | # v e ----------------------------- # DENY # # Source networking configuration. . /etc/sysconfig/network
# Check that networking is up. [ ${NETWORKING} = "no" ] && exit 0
Det er første gang jeg laver en firewall og har kigget på en der virker på arbejdet. Ham som har lavet firewallen arbejder der ikke mere så jeg kan ikke spørge ham.
Men som jensendk sier i det aller første innlegg: "Begge dine netkort er på samme subnet.. ret dit ene subnet til noget andet." Og subnetmaske er 255.255.255.0 ... Dette skulle da heller ikke kunne fungere ? Dersom SpeedStream router kunne få 192.168.1.1, 192.168.2.1 eller 192.168.4.1 så kunne det vel fungere. Man kan vel ikke route fra og til det samme nettverksegment ??
Alternativt så kan speedstream stå slik som den er og så får LAN nummer i serien 192.168.1.x, 192.168.2.x eller 192.168.4.x serien eller hva som måtte passe med det øvrige.
Dine ip adresser kunne muliggens ha fungert med en annen subnetmaske enn 255.255.255.0 men å sette opp og route nettverk på denne måten er ofte ønødvendig komplisert. Har du mulighet til å skifte ip adresser slik at du får to adskilte nummerserier på hver side av routeren. Gi beskjed så legger jeg et par opplysninger til hvis du har mulighet til dette.
På den annen side så finnes ikke kall til den kernel modul som skal støtte for -m state --state ESTABLISHED,RELATED så viss ikke denne allerede er lastet som default ...
modprobe ip_conntrack
Det er heller ikke satt opp noen DNAT eller noen SNAT altså ingen ting som skulle sette opp den trafikken som filter rules skulle forholde seg til ..
Litt spesielt .... Litt uvanlig og spesielt, men det kunne vel faktisk kanskje fungere og da med de ipadreesene som allerede er, men da med en annen subnettmaske enn 255.255.255.0 Dette virker som et uvanlig firewall design, men det virker gjennomtenkt ..
For en firewall løsning som fungerer "på vanlig måte" og med korekt eller okløsning for statefeull inspection gå til danks firewall generator: http://iptables.linux.dk Anbefales !
For å oppsummere litt, for dette ble litt rotete da jeg mener å ha oppdaget tingene sånn litt etter hvert:
1. Scriptet over er ikke satt opp som et standard firewall script med nat. I stedet ser det ut som man benytter et prinsipp om opdeling i subnettverk "i den samme nummerserie". Dette kan kjøre dersom man finner fram til den riktige subnett maske som ikke kan være 255.255.255.0 Det at firewall ikke kan forwarde er sånn sett ikke utrykk for at en liten feil men grunnleggende ting som ikke fungerer.
2. Det er sansynligvis mulig å finne fram til en "rett" subnettmaske som får scriptet til å fungere, men dersom man gjør det så har man et script kjørende som er satt opp til å fungere forskjellig fra de fleste andre script. Dette kan gjøre feilsøking og vedlikehold litt problematisk. Dersom du finner fram til rett subnettmaske så er det sannsynligvis ikke nødvendig å skifte ut ip adressene slik som jeg foreslo først.
3. Et annet alternativ er å skifte ut ip adressene, bruke en nettverksmaske 255.255.255.0 og å lage noen andre små endringer i firewall som er i samsvar med dette, dvs bla å få på plass nat / masquerading.
4. Siste alternativ er sansyligvis det klart enkleste. Lag et nytt script med dank sin script generator. Dette vil sansynligvis medføre at du får nat/masquerading i to nivåer, først i speed stream router og der etter en gang til i Linux maskin. Dette kan fungere helt ok og 100 % bra. "Bruker en slik "dobbelt masquerading" selv og det fungerer uten problemer.)
Tak for Jeres henvendelser og i må undskylde at jeg ikke havde skrevet tilbage før nu (fik gæster :-)). Men nu vil jeg prøve noget af alt det I skriver.
Bruker et tilsvarende oppsett med Netopia ADSL modem/router/firewall etterfulgt av en Linux router/firewall. Har ikke oppdaget noen ulemper med dette, snarere tvert i mot. Det fungerer bra.
Hei Rubber ! Har testet ditt script og fått det til å virke etter noen små endringer:
#!/bin/bash
# firewall # # Starter, stopper og restarter firewall # # # ---------------------------------------------------------------- # | ACCEPT/ lo interface # v REDIRECT _______ | # --> C --> S --> ____--> D--> ~~~~~~~~ -->|FORWARD|----> _______ --> # h a |INPUT | e {Routing } |Chain | |OUTPUT |ACCEPT # e n |Chain | m {Decision} |_______| --->|Chain | # c i |______| a ~~~~~~~~ | | -> |_______| # k t | s | | | | | # s y | q | v | | | # u | v e v DENY/ | | v # m | DENY/ r Local Process REJECT | | DENY/ # | v REJECT a | | | REJECT # | DENY d ---------------------| # v e ----------------------------- # DENY # # Source networking configuration. . /etc/sysconfig/network
# Check that networking is up. [ ${NETWORKING} = "no" ] && exit 0
# See how we were called. case "$1" in start) if [ -e $LOCK_FILE ]; then echo "$PROG_NAME already running." exit 1 fi touch $LOCK_FILE echo -n "Starting $PROG_NAME..." # Set proc sikkerhedsflag echo 1 > /proc/sys/net/ipv4/tcp_ecn echo 1 > /proc/sys/net/ipv4/conf/all/rp_filter echo 1 > /proc/sys/net/ipv4/tcp_syncookies echo 1 > /proc/sys/net/ipv4/icmp_echo_ignore_broadcasts echo 1 > /proc/sys/net/ipv4/icmp_ignore_bogus_error_responses echo 0 > /proc/sys/net/ipv4/conf/all/accept_redirects echo 0 > /proc/sys/net/ipv4/conf/all/accept_source_route echo 1 > /proc/sys/net/ipv4/ip_forward # Hent moduler, der ikke bliver suget automatisk /sbin/modprobe -s ip_conntrack_ftp ### Set policies og flush gamle regler iptables -F iptables -t nat -F iptables -t mangle -F iptables -X iptables -P INPUT DROP iptables -P FORWARD DROP iptables -P OUTPUT ACCEPT # Input on local interface ok iptables -A INPUT -i lo -j ACCEPT iptables -A OUTPUT -o lo -j ACCEPT
# Trafik paa hoeje porte og ICMP iptables -A FORWARD -p TCP -i $INSIDE_IF -j ACCEPT iptables -A FORWARD -p UDP -i $INSIDE_IF -j ACCEPT iptables -A FORWARD -p TCP -i $OUTSIDE_IF ! --syn --dport 1024: -j ACCEPT iptables -A FORWARD -p UDP -i $OUTSIDE_IF --dport 1024: -j ACCEPT iptables -A FORWARD -p ICMP -j ACCEPT
# Accepter trafik mellem relaterede porte (ftp <> ftp-data) # Endret litt Langbein iptables -A FORWARD -i INSIDE_IF -m state --state ESTABLISHED,RELATED -j ACCEPT
# FIREWALL iptables -A INPUT -p ICMP -j ACCEPT iptables -A INPUT -p TCP -d $INSIDE_IP ! --syn -j ACCEPT iptables -A INPUT -p UDP -d $INSIDE_IP -j ACCEPT iptables -A INPUT -p TCP -d $OUTSIDE_IP ! --syn -j ACCEPT iptables -A INPUT -p UDP -d $OUTSIDE_IP -j ACCEPT iptables -A INPUT -p UDP --sport 500 --dport 500 -j ACCEPT iptables -A INPUT -p 50 -j ACCEPT iptables -A OUTPUT -p 50 -j ACCEPT iptables -A INPUT -p 51 -j ACCEPT iptables -A OUTPUT -p 51 -j ACCEPT iptables -A INPUT -p TCP -d $INSIDE_IP --dport ssh -j ACCEPT iptables -A INPUT -p UDP -d $INSIDE_IP --dport ssh -j ACCEPT
# Endring, Langbein
iptables -A INPUT -p UDP --dport 53 -j ACCEPT iptables -A INPUT -p TCP --dport 80 -j ACCEPT
Har ikke testet alle funsjoner, dette ser forresten galt ut: # Endret litt Langbein iptables -A FORWARD -i INSIDE_IF -m state --state ESTABLISHED,RELATED -j ACCEPT
Firewall scriptet over ser ut til å være bygget over grunnleggende design og funsjonsfeil, selv om det altså "fungerer".
Feilen ligger i den måte som de ulike firewall chains et forutsatt å skulle fungere sammen på. Dette er ellers en ganske vanlig feil som går igjen i mange iptables firewall script man kan finne rundt om på webben.
Tidligere Linux cernels hadde en slik funsksjonalitet og en slik dataflow som det firewall script over ser ut til å forutsette, der det faktisk skjedde en dobbelt filtrering, først gjennom input chain og så gjennom forwarding chain.
I cernel 2.4.x og ved bruk av iptables, så er ikke lengere de to firtering chains "seriekoplet" slik som scriptforfatteren faktisk har tegnet inn i sin figur. I dag så kjører de to filtering cahains paralelt ved siden av hverandre slik at input chain ikke gir noen filtreing av trafikken gjennom forwarding chain, dvs at trafikken utenfra til lan kanskje blir kjørende uten filtreing hvis filteing rules er lagt til input chain.
Man skulle kansjje tro at dette var meget galt, men tja ...
Når man benytter invendige lokale adresser i nummerserien for interne adresser, så er disse i utgangspunktet ikke routbare over internett, det vil si at det i utgangspunktet ikke er mulig å nå fram til disse adressene via internett. I dette ligger en del beskyttelse.
Scriptet over kan vel sånn sett brukes ?!
Vil anbefale at scriptet over brukes for uttesting av hvordan en firewall kan virke men at det mer permanente scriptet blir laget med utgangspunkt i danks "firewall generator" der det hele blir satt opp "riktig" fra bunnen av.
Scriptet over inneholder ellers mange veldig interesante detaljer, for eksempel start og stop og andre ting som man eventuelt kunne ta med seg over i et annet script for eksempel det scriptet som blir laget av firewall generator.
# --> C --> S --> ____--> D--> ~~~~~~~~ -->|FORWARD|----> _______ --> # h a |INPUT | e {Routing } |Chain | |OUTPUT |ACCEPT # e n |Chain | m {Decision} |_______| --->|Chain | # c i |______| a ~~~~~~~~ | | -> |_______|
jamen det er fint det virker nu. Synes også det var ret underligt, men hvis det var hardwaren er der jo ikke noget at sige til det :)
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.
