IPTables intern webserver

Skal man tilgå din interne server via port 4000 ?

Ja, på port 4000. Ved ikke om det har noget at gøre med at jeg anvender MASQURADE på postrouting? Det skal lige siges at jeg har 2 WAN nic (to , og et LAN nic. Lad os bare sige:

EHT0=80.0.0.1
ETH1=80.0.0.2
ETH2=10.0.0.1
LANWEB=10.0.0.2

Når jeg så vil tilgå min webserver (LANWEB), skriver jeg i adresse linien:
http://80.0.0.1:4000

- og har indført denne regel i firewall:
iptables -t nat -A PREROUTING -i eth0 -p tcp --sport 1024: --dport 4000 -j DNAT --to-destination 10.0.0.2

Og som sagt tilladt alt på FORWARD kæden i første omgang.

NB. IIS er sat op til at lytte på port 4000. Det virker hvis jeg i adresse linien skriver:
http://10.0.0.2:4000

Derudover har jeg luret, at hvis jeg indfører denne regel:
iptables -t nat -A POSTROUTING -d 10.0.0.2 -p tcp --dport 4000 -j SNAT --to-source 10.0.0.1

- ja, så virker det hvis jeg skriver http://80.0.0.1:4000, hvis jeg gør det fra lokalt fra webserveren. Men så snart jeg gør det fra en maskine udenfor netværket, virker det ikke.

Hej Thomas-k
Du skal vist have portnummeret på til aller sidst, det virker i hvert fald hos mig.

iptables -t nat -A PREROUTING -i eth0 -p tcp --sport 1024: --dport 4000 -j DNAT --to 10.0.0.2:4000

Har du et 1-tal i /proc/sys/net/ipv4/ip_forward ?

Først det som jeg tror er en liten syntaks feil:

"--sport 1024:" Det skal vel ikke være noen kolon (:) bak 1024 ?

Ellers så er det ikke så lett å helt se i hvilke praktiske tilfeller denne regelen skulle komme til å slippe gjennom trafikk:

iptables -t nat -A PREROUTING -i eth0 -p tcp --sport 1024 --dport 4000 -j DNAT --to 10.0.0.2:4000

Over så står det altså: Alle pakker som har port 1024 som avsenderport og port 4000 som adresseport skal videresendes til ip 10.0.0.2 til den samme port 4000 (??)

Er det dette som er meningen, eller er det slik at de ip pakkene som når den ekstene ip på port 1024 skal videresendes til port 4000 på den interne serveren ??

Da blir det vel i så fall omtrent slik:

iptables -t nat -A PREROUTING -i eth0 -p tcp --dport 1024 -j DNAT --to 10.0.0.2:4000

Ellers så er det vel rett nok som pzyko sier at portnumret der som  pakken skal sendes skal stå bak ip adressen.

"Ved ikke om det har noget at gøre med at jeg anvender MASQURADE på postrouting?"

Det skulle være en helt annen problemstilling som ikke berører saken.

langbein > grunden til at der er : efter 1024 er at det trafikken kommer fra port 1024 eller højere, altså en upriviligeret port, og ikke kun porten selv. Hvis man vil definere et port range benytter men : f.eks. 1024:1055 hvis man ikke skriver noget efter : går ranget til port 65535 som er den højeste mulige port.

Jeg har også prøvet med postnummer til sidst, men det hjalp desværre ikke. Der routes også fint mellem netkort, da alle andre udegående regler ellers ikke ville virke. Som pzycho siger, anvender jeg 1024: til at difinere alle uprivilligerede porte. Hmm, kan ikke hitte ud af hvad der er galt... men prøv at studs over mit andet indlæg...hvorfor får jeg lov lokalt fra webserveren, og ikke udefra???

pzycho -> Takker for info om dette med : for det viste jeg ikke.

Hvis det ellers ikke fungerer funger så kan det være en ide å forenkle litt til det kjører og så eventuelt bygge opp igjen med mer komplekse rules.

Hvis situasjonen alså er den at det kjører en eller annen server inne på lan med tcp port 4000 og denne servern også skal være tilgjengelig eksternt via den samme port 4000, så forsøk dette:

iptables -t nat -I PREROUTING -i eth0 -p tcp --dport 4000 -j DNAT --to 10.0.0.2

(Legg merke til at -A er skiftet ut med -I for å plassere regelen øverst i rule stack.)

Ellers så vil jo heller ikke denne regelen fungere uten en tilsvarende og korenponderende regel som åpner for forward chain. For feilsøking, forsøk med policy sat til ACCEPT for forward chain.

Ja, mine tests har også bygget på at åbne FORWARD som standard. Men tror jeg prøver at flushe alle regler, åbne for alle chains, og kun tilføje prerouting reglen. Afprøver det lige i morgen og vender tilbage.

Hmm, fatter ingenting... Jeg flusher alle regler, åbner for alle kæder og tilføjer:

iptables -t nat -A PREROUTING -i eth0 -p tcp --sport 1024 --dport 4000 -j DNAT --to 10.0.0.2:4000

- stadig virker det ikke? Nogle forslag?

Evt. nogle som kan copy/paste deres firewall, med samme prerouting regel?

Dette skulle vel normalt heller ikke fungere Hvordan har man kontroll på at sport er 1024 ? Hva skjer hvis du tar vekk hele kravet til source port ?

Forsøker bare være litt kreativ ..

Har i noen få helt spesielle tilfeller vært ute for at angivelse av adapter ikke har virket. Har da knyttet regel opp mot ip adresse i stedet. (Men dette har vært i forbindelse med en firewall som kjørte ut fra et bridge mode prinsipp.)

Hej Langbein. Bare bliv ved med at være kreativ, da det er det jeg har brug for i denne situation. Kan simpelthen ikke finde ud af hvad der "blokere". Grunden til at man ved at det er port 1024 eller derover er fordi en forbindelse ser således ud:

Frem: Klient -> port 1024: --------- Modtager -> port 80
Tilbage: Modtager -> port 80 ---------- Klient -> port 1024:

Som klient sender du altid upriviligeret, og modtager på en upriviligeret port.

Jeg har faktisk prøvet forsøget på to forskellige netværk nu uden held, så tror der en noget jeg mangler i firewall scriptet???

Fra det over:

Lad os bare sige:


EHT0=80.0.0.1
ETH1=80.0.0.2
ETH2=10.0.0.1
LANWEB=10.0.0.2

Hvor reelt er dette ? Her er det jo angitt fire kort og kun 2 subnett. Det skulle vel ikke kunne kjøre ?? Hvordan ser de virkelige ip adressene ut ?

Setup er som følgende (IP adresser er eksempler):

Eth0=80.0.0.1 (WAN IP)
Eth1=80.0.0.2 (WAN IP)
Eth2=10.0.0.1 (LAN gateway)
LANWEB=10.0.0.2 (Webserver som er tilkoblet LAN gateway)

Dvs. at der er 2 WAN linier ind i Linux boksen, og en LAN linie til det indre netværk. På det indre LAN netværk står der tilkoblet en Webserver.

På selve Linux boksen findes der allerede en webserver (80.0.0.1) som anvender port 80. Derfor vil jeg gerne videresende al trafik på port 4000 til den indre webserver (10.0.0.2). Grunden til at jeg ikke vil anvende Linux boksen som webserver med virtual websites, er fordi Linux boksen kører Apache, mens den indre webserver (10.0.0.2) skal kører iis.

Så kort fortalt: Alt trafik på port 4000, skal videresendes fra 80.0.0.1, til 10.0.0.2. Håber dette gav en bedre uddybelse.

Men dette er vel ingen standard måte å dele opp et nettverk på. Det drier seg altså om to stk subnet som hver for seg har 2 netverksadaptere. Har aldri sett noe slikt beskrevet i teorien rundt Linux firewalls og det er ikke godt å si hvordan dette eventuelt skulle fungere. Med en slik inndeling i to subnett og 4 nettverkskort så ville jeg da ikke forvente at den aktuelle forwarding regel skulle fungere, hvilket den heller ikke gjør. (Standard Linux firewall måte å gjøre dette på det ville jo være å dele opp i fire subnett og i stedet for to og så route trafikken mellom disse fire subnettene. Da skulle man forvente at den aktuelle forwarding regel skulle kunne fungere.)

Altså for eksempel:

Eth0 = 80.0.0.1/255.255.255.0 (Nettverk no 80.0.0 )
Eth1 = 80.0.1.1/255.255.255.0 (Nettverk no 80.0.1 )
Eth2 = 10.0.0.1/255.255.255.0 (Nettverk no 10.0.0 )
Eth3 = 10.0.1.1/255.255.255.0 (Nettverk no 10.0.1 )

Slik som det er delt inn fra før så er det jo bare delt inn i to nettverk i stedet for fire:

Eth0 og Eth1 = Nettverk 80.0.0
Eth2 og Eth3 = Nettverk 10.0.0

Har aldri sett beskrevet i teorien rundt Linux firewalls hvordan det kan være mulig å kjøre to og to adaptere på det samme nettverk. (Det er ikke dermed sagt at det ikke kan la seg gjøre, men det er nok en rimelig forklaring på hvorfor prerouting setningen ikke fungerer.)

Noen framskritt.

??

Nej, jeg er ved at opgive efterhånden for en stund. Men du misforstår også en smule langbein fordi:

eth0 = 80.0.0.1/255.255.255.252 (bemærk 252)
eth1 = 80.0.0.2/255.255.255.252
eth2 = 10.0.0.1/255.0.0.0

Og så skriver du eth3...jeg er bange for at vi taler fobi hinanden når du skriver sådanne, for 10.0.0.2 netkortet sidder ikke i firewall'en (bare lige så jeg er sikker på at vi ikke taler forbi hinanden).

Men cool at du gider at hjælpe, da jeg har brug for at diskutere setup for at komme videre i processen.

Ud fra det du siger, så skal firewall gateway og webklient altså kører på to forskellige subnets før det virker?

Tror det skal komme til å fungere, hvis du bare ikke gir opp ..

Kommer virkelig 80.0.0.1 og .2 på hvert sitt subnett når masken er 252 ?? Trodde ikke, det men det er godt mulig ..

Jo, standard måte å kjøre en linux firewall på det er i "routing mode", det vil si at hvert enkelt av nettverksadapterne skal tilhøre hvert sitt subnett for at det hele skal kjøre "som normalt" og "ut fra boken". (Man kan også kjøre den i bridge mode, og det er den annen hovedmåte. Her kan man enten sette ingen ip, en ip for bridgen eller også for hvert enkelt kort så vidt jeg husker. Kun en enkelt for de to bridgede kortene er vel det mest vanlige.)

Alle tre kortene skal kjøre på hver sine subnett for at en standard konfigurering skal virke.

Forsøk dette:

iptables -t nat -A PREROUTING -d 80.0.0.1 -p tcp --dport 4000 -j DNAT --to 10.0.0.2
(Forsøk eventuelt å bytte om rekkefølgen for -d -p --dport)

(Ikke legg på noe kriterium for --sport til å begynne med.)

Så vidt som jeg kan se (men sikker er jeg ikke) så ligger 80.0.0.1 og 80.0.0.2 fortsatt på det samme subnett når masken er 252. (De to siste bits angir noden og de øvrige nettverket.)

Nettverk 0
000 = 0
001 = 1
010 = 2
011 = 3

Nettverk 1
100 = 4
101 = 5
110 = 6
111 = 7

80.0.0.1 og 80.0.0.5 skulle vel komme på hver sine subnett meed masken 253 ??
(Men ikke 80.0.0.1 og .2)

Det kan tenkes at den siste preroutingen vil virke uansett (??)

Grunnen til at jeg tror at denne kan virke allikevell, det er at jeg har en teori om at -eth0 uansett internt i linuxgatewayen vil bli oversatt til en ip adresse og at det er denne "oversettningen" som ikke fungerer. Ved å angi ip adressen direkte, så skulle man kunne kompensere for denne feilen (formodentlig som følge av at 80.0.0.1 og .2 ligger på samme subnett.)

Altså for å elemeninere denne feilkilden:
iptables -t nat -A PREROUTING -d 80.0.0.1 -p tcp --dport 4000 -j DNAT --to 10.0.0.2

Bare en teori ..

Aternativs så kan man jo skifte om ip adresser til de to på 80. nettverket, hvis dette er mulig.

Ja, jeg forsøger det lige i morgen. Har ikke mulighed for at teste det før udefra. Men i første omgang prøver jeg at anvende forskellige subnets, for at se om det hjælper. Så vender jeg lige tilbage i morgen.

Framskritt ? (Holder akkurat på å gå gjennom boken Linux Firewalls 3'rd edition, så det passer bra med litt remote laboppsett :-)

:-) Nej, desværre. Kan simpelthen ikke få det virke??? Har prøvet på forskellige subnets, uden det hjalp. Så er lidt derhenne af hvor jeg opgiver.

Nei, det går ikke an å gi opp. Du har jo ennå ikke helt begynt, he, he.

Foreløpig så har vi jo ikke en gang begynt å bruke "de normale redskapene" for å teste en firewall.

Hvilken distro dreier det seg egentlig om ?

Tar du sjansen på å gi meg en midlertidig root logon, helst både på gateway og også på intern webserver ?

Er det eventuelt mulig å installere iptraf (trafikkmonitor) + ethereal (trafikklogger) + nmap (portscanner) på gateway pluss på intern server ?
(Da går det rimelig hurtig å se hvor feilen ligger.)

Har du selv console tilgang til begge PC'ene ? (Ved remote konfigurering og testing av firewall er det nokså hurtig gjort å låse seg selv ute. Et sekund uoppmerksomhet og et tastrykk feil, såe r det gjort ..)

Hvis eventuelt ja så kan du maile pålogging til heiarne at gmail dått com.

Jeg sender dig lige en mail langbein, så vi kan tales ved der...