iptables konfiguration

Det är lite oklart exakt vad du behöver hjälp med, och jag ska ju inte göra dina hemuppgifter, men jag slänger ur mig lite ofullständig, otestad kod som kanske skulle kunna leda dig på rätt spår:

-A PREROUTING -t nat -i eth0 -p tcp --dport 80 -j DNAT --to 192.168.0.100:8080
-A FORWARD -p tcp -i eth0 -o eth1 -d 192.168.0.100 --dport 8080 -j ACCEPT
-A POSTROUTING -t nat -j MASQUERADE -o eth1

Jag noterar också att du släpper in vilken skit som helst på de portar du öppnat, tex:

-A INPUT -p tcp -m tcp --dport 143 -j ACCEPT

Du kanske istället borde överväga att skriva reglerna på formen (otestat ur huvudet):

-A INPUT -p tcp -m tcp --dport 143 -m conntrack --ctstate NEW -j ACCEPT

Förbindelsen fungerar därför att du har följande regel som fångar upp förbindelser som är etablerade eller på väg att etableras:

-A INPUT -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT

Om du inte filterar på NEW blir denna regel rätt meningslös eftersom allt konstigt ändå slinker igenom brandväggen. Om du gör enligt mitt förslag spärrar brandväggen exempelvis paket som påstår sig komma från etablerade förbindelser men inte gör det. Det är det som är SPI, Stateful Packet Inspection.

En liten extra svårighetsgrad med SPI är att hantera FTP eftersom det är två olika portar inblandade. Det finns dock iptables-moduler för att hantera detta. Lämnas som en övningsuppgift till läsaren!

Om du vill använda på SPI även på din forwardade port behöver du nog krydda med lite NEW-, RELATED- och ESTABLISHED-koll där också i forward-kedjan, på samma sätt som jag förelagit för INPUT-kedjan.

Ytterligare ett litet tips (överkurs): Det finns en multiport-modul i iptables om du vill slå ihop alla dina öppna portar (max 15 stycken) i ett uttryck.

Slutligen, som jag redan skrivit flera gånger: Allt är otestat, och jag hoppas att jag inte förvirrar dig mer än jag hjälper.

-A INPUT -p tcp -m tcp --dport 143 -m conntrack --ctstate NEW -j ACCEPT

-A INPUT -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT

Du har fattat rätt och precis som i din ursprungliga kod är det brukligt att ha RELATED-,ESTABLISHED-uttrycket tidigt i kedjan eftersom de allra flesta paket som går genom brandväggen tillhör redan etablerade förbindelser. NEW är relativt ovanligt, och det kan man kolla senare.

Det är i NEW-uttrycket man försöker filtrera bort så mycket oönskad trafik som möjligt. Överkurs: En möjlig enkel utökning av din kod, om du senare kommer använda din kod i verkliga livet, är att använda limit-modulen för att skydda dig mot överbelastningsattacker genom att bromsa antalet nya förbindelser. Man utökar alltså uttrycket med något liknande:

-m limit --limit 5/s --limit-burst 10

Dessa värden är naturligtvis alldeles för låga för en webb-server, men kanske är mer rimliga på exempelvis en SSH-port.

Det finns många kul moduler att upptäcka i iptables!

-A PREROUTING -t nat -i eth0 -p tcp --dport 80 -j DNAT --to 192.168.0.100:8080

Jepp! Man skriver om destinationsadress och destinationsport helt enkelt.

-A FORWARD -p tcp -i eth0 -o eth1 -d 192.168.0.100 --dport 8080 -j ACCEPT

Nästan rätt. "-o eth1" skickar inte ut paketen på eth1 utan det är istället så att regeln matchar de paket som är på väg till eth1. Datorns routingtabell sköter själva forwardingen till eth1 automatiskt förutsatt att du aktiverat ip_forward-direktivet som det står i din labbanvisning. Om allt i systemet funkar som det ska så ska väl inga paket med 192.168.0.100-destination kunna vara på väg någon annanstans än eth1 om de kommer från eth0 och man kan därmed ifrågasätta om "-o eth1" verkligen behövs. Men nu handlar det ju om brandväggsregler och då kan det vara bra att vara petnoga och kolla så att allt verkligen stämmer innan man godkänner paket. En av brandväggens uppgift är ju att döda konstig trafik som av någon anledning kommit på avvägar. Om alla vore snälla och allt jämt funkade som det skulle så behövs ju knappt någon brandvägg, men...

-A POSTROUTING -t nat -j MASQUERADE -o eth1

Det stämmer.

"--to-destination" ska det vara. Det var jag som skrev koden fel ur huvudet.

-A POSTROUTING -t nat -i eth1 -p tcp -s 192.168.0.100 -j SNAT --to-source 130.239.117.174

Det stämmer att SNAT rekommenderas framför MASQUERADE om man har en statisk ip men i praktiken fungerar MASQUERADE oftast förträffligt i båda fallen. Att använda SNAT är dock en optimering. MASQUERADE tvingas ta reda på gränssnittets ipadress för varje paket (den kan ju ha ändrats alldeles nyss), medan den i en SNAT-regel är hårdkodad och inte kräver någon uppslagning.

-A PREROUTING -t nat -i eth0 -p tcp --dport 80 -j DNAT --to-destination 192.168.0.100:8080
-A FORWARD -p tcp -i eth0 -o eth1 -d 192.168.0.100 --dport 8080 -j ACCEPT
-A POSTROUTING -t nat -i eth1 -p tcp -s 192.168.0.100 -j SNAT --to-source 130.239.117.174

Det ser väl rätt OK ut. Jag har ingen vana att använda SNAT, men det som slår mig spontant är att du kanske behöver ta hand om 8080 -> 80 översättningen åt andra hållet också när du kör SNAT. Om dina brandväggsregler inte funkar så är det ett tips att kolla mer på.

Och så kan du ju överväga att dela upp FORWARD-regeln i två separata regler för att köra stateful packet inspection även på denna trafik. En striktare regel som tar hand om NEW, och en slappare regel som tar hand om förbindelser som redan är RELATED,ESTABLISHED - allt på analogt sätt som du hanterar trafiken i INPUT.

Jag har grubblat på detta ytterligare några minuter.

Om du inte gör som jag föreslagit och använder "-m conntrack --ctstate RELATED,ESTABLISHED" i en FORWARD-regel kommer du kanske få problem med utgående trafik, förutsatt att du inte löser det på annat sätt. Som det ser ut nu har du ingen FORWARD-regel som tillåter trafiken att passera ut från webbservern. Du skriver visserligen om eventuella paket från webbservern i POSTROUTING-kedjan, men eftersom det saknas en FORWARD-regel som tillåter dem att passera ut kommer de kanske aldrig att nå dit.

Nu är det tydligen så att "-t nat" är lite klurigt och kanske redan fixar detta på något sätt. Jag drar mig till minnes att det var någonting med att regeln bara matchade första paketet och sedan var allt tillåtet. Jag är lite dåligt påläst där. Men om din brandvägg inte funkar så har du i alla fall ett uppslag var du ska börja leta.