Iptables - gået istå

Prøv at se på dette link http://www.sslug.dk/sikkerhed/netfilter.html Her er et eksempel med NAT og PORT forwarding

>> iptables -P INPUT DROP
>> iptables -P FORWARD DROP
>> iptables -P OUTPUT ACCEPT

>> Har jeg forstået det korrekt, at ovenstående lukker for al indgående og åbner for alt udgående?

Forsaavidt ja, men bare naar det gjelder de lokale prosesene som kjoerer paa firewall
maskinen.

Forandrer du slik:

iptables -P INPUT DROP
iptables -P FORWARD ACCEPT
iptables -P OUTPUT ACCEPT

Saa har du i utganspunktet mulighet for nat (delt internettforbindelse) og
dnat, dvs forwarding til innvendig server.

FORWARD chain styrer muligheten for trafikk gjennom firewall maskinen.

Enten saa kan man sette policy til ACCEPT. Da tillater man i utgangspunktet all slags
trafikk gjennom firewall maskinen eller saa kan man sette policy til DROP og saa sette
opp en serie med spesialregler som aapner for en og en port. Dette vil sikkerhetsmessig
vaere den sterkeste loesningen.

Dine regler vil IKKE fungere.

iptables -P INPUT DROP
iptables -P FORWARD DROP
iptables -P OUTPUT ACCEPT

Dette vil medføre, at når du forsøger at lave en forbindelse til eksempelvis eksperten.dk, så sender du først en pakke (SYN) til www.eksperten.dk. Denne svarer tilbage med en anden pakke (SYN/ACK). Denne pakke bliver imidlertid fanget pga. "iptables -P INPUT DROP". Det samme vil gøre sig gældende for alle andre forbindelser..

For at undgå dette, så udvider vi dit regelsæt en lille smule..
iptables -P INPUT DROP
iptables -A INPUT -j accept -m state --state ESTABLISHED,RELATED
iptables -P FORWARD ACCEPT
iptables -P OUTPUT ACCEPT

Dette er har så kun noget at gøre med forbindelser fra/til linux-maskinen selv. Det vedrører ikke de forbindelser, der blot går igennem.

Forwarding af forbindelser til port 20,21 og 80:
iptables -t nat -A PREROUTING -j DNAT -i eth0 -p tcp --dport 20,21,80 --to-destination 192.168.1.100
iptables -A FORWARD -o eth1 -p tcp -m state -d 192.168.1.100 --state NEW,ESTABLISHED

NAT klares således:
iptables -t nat -A POSTROUTING -j MASQUERADE -i eth1 -o eth0
iptables -A FORWARD -j ACCEPT -i eth1
iptables -A FORWARD -j ACCEPT -i eth0 -m state --state ESTABLISHED,RELATED


Intet af dette er testet, så lad mig lige vide, om det fungerer tilfredsstillende.

Linuxkonsulent ->
"Denne pakke bliver imidlertid fanget pga. "iptables -P INPUT DROP". Det samme vil gøre sig gældende for alle andre forbindelser.."

Dette er feil. Slik fungerte det ved konfigurering av ipchains.

Den kanskje stoerste og viktigste revisjonen fra ipchains til iptables var at man skilte ad filtreringen av trafikk til de lokale prosessene paa firewall maskinen og filtreringen av trafikk til maskiner bak firewall maskinen. input chain filtrerer naa bare trafikk til lokale prosesser i motsetning til tidligerer i forbindelse med ipchains da den baade filtrerte trafikk til lokale prosesser og til maskiner bak firewall.

http://www.telematik.informatik.uni-karlsruhe.de/lehre/seminare/LinuxSem/downloads/netfilter/iptables-HOWTO-5.html

iptables:
Trafikk til lokale prosesser filtreres naa via input chain.
Trafikk til maskiner bak firewall filtreres via forward chain.

ipchains:
Trafikk til lokale prosesser og maskiner bak firewall filtreres via samme input chain.

Beklager, se her, du har jo skrevet det selv, huff:
"Dette er har så kun noget at gøre med forbindelser fra/til linux-maskinen selv. Det vedrører ikke de forbindelser, der blot går igennem."
La ikke merke til denne setningen foer etterpaa !!

Naar det ellers gjelder firewall saa tror jeg at jeg ville tatt sjansen paa aa la forward chain staa aapen for aa forenkle litt. Grunn: De interne adressene er jo ikke routbare, dvs de er ikke addresserbare via internett i det hele tatt. Har tenkt en del paa dette og kan egentlig ikke se noen grunn til at ikke forward chain skulle kunne staa aapen saa lenge det ikke finnes globalt adresserbare adresser paa det interne nettverket. (Er ikke 100 % sikker paa at denne tanken er korrekt, men synes det hoeres riktig ut.)

Paa den annen side hvis det ikke skal skje noen lokal trafikk til de lokale prosessene paa firewall maskinen, saa ville jeg av sikkerhetsmessige grunner valgt en DROP policy her uten noen form for regel som gir aapning for innput chain, hvis ikke dette er noedvendig.

#!/bin/bash

# Sette til forwarding
echo 1 > /proc/sys/net/ipv4/ip_forward

# Laste ekstra kernel modul for ftp (ikke helt sikker på denne)
modprobe ip_conntrack_ftp

# Flushe chains
iptables --flush
iptables -t nat --flush
iptables -t mangle --flush

# Sette policies
iptables --policy INPUT DROP
iptables --policy OUTPUT ACCEPT
iptables --policy FORWARD ACCEPT

# Sende pakker til server bak firewall
# Forutsetter eth0 mot internet

iptables -t nat -A PREROUTING -i eth0 -p tcp -d 192.168.1.1 --dport 20,21,80 -j DNAT --to-destination 192.168.1.100

# Delt internettforbindelse

iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE

Har ikke testet jeg heller.

Har testet denne. Den fungerer men inneholdert ikke alt:

#!/bin/bash

modprobe ip_conntrack_ftp

CONNECTION_TRACKING="1"

echo 1 > /proc/sys/net/ipv4/ip_forward

iptables --flush
iptables -t nat --flush
iptables -t mangle --flush

iptables --policy INPUT DROP
iptables --policy OUTPUT ACCEPT
iptables --policy FORWARD ACCEPT

iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE

hvad betyder:

modprobe ip_conntrack_ftp ????

Det betyder, at man gerne vil have modulet "ip_conntrack_ftp" indlæst. Det er det modul, der kan gennemskuye, at når der kommer en forbindelse ind, der relaterer til en eksistrende ftp-forbindelse, så er det i orden, at den kommer igennem.

Det har Linuxkonsulent rett i. En kernelmodul kan enten vaere en statisk del av kjernen ved at den er kompilert inn til aa vaere dette, eller den kan lastes inn dynamisk via modprobe kommando. ip_conntrack_ftp er en kjernemodul som supporter ftp trafikken.

Det scriptet over som er testet er hentet fra en Red Hat 7.3 som jeg satte opp for noen uker siden. Er egentlig ikke sikker paa om setningen
modprobe ip_conntrack_ftp egentlig behoeves, dersom denne modulen allerede
er en statisk del av RH 7.3 kernel. Vil tro at det ikke skulle medfore noe
problem om man laster samme modul en gang til (?)

Naar det gjelder denne setningen:
CONNECTION_TRACKING="1"
Saa er jeg hverken helt sikker paa hva den gjoer eler hvordan den fungerer.
(Man kan eventuelt forsoeke aa eksprimentere med aa krysse bort noe av
dette, altsaa kommentere ut.) (slik: # CONNECTION_TRACKING="1")

linuxkonsulent -> dersom du finner tak i noen opplysninger som sier at resonementet eller tankegangen rundt det med at forward chain risikofritt skal kunne staa aapen paa grunn av ikke routbare adresser, kan du i saa fall legge ut info her !?

Har forsoekt aa diskutere prinsippet i diskusjonsgrupper og har saa langt ikke funnet noe argument som sier at dette er en sikkerhetsrisiko. Bruker prinsippet selv i del firewall sammenheng og ville vaere kjempe interresssert i opplysninger om eventuelle sikkerhetsmessssige svakheter ved denne loesningen.

Naar det gjelder denne setningen:
iptables -t nat -A PREROUTING -i eth0 -p tcp -d 192.168.1.1 --dport 20,21,80 -j DNAT --to-destination 192.168.1.100

Det som er kjempetricky med adsl forbindelser det er at det ofte foregaar routing + nat inne i selve modemet/routeren. Naar man saa setter til en Linux firewall saa faar man faktisk nat i 2 nivaaer, foerst i routeren og saa i Linux maskinen. Hva blir saa den <eksterne ip adresssen> for preroting setningen.

Jeg tror det i dette tilfelet blir 192.168.1.1 men dette kan vaere feil, det kan ogsaa tenkes aa vaere den virkelig eksterne ip adresssen.

Narr man lager firewall script saa loenner det seg aa begynne med noe som allerede er testet og saa legge til en og en linje, mens man trinnvis proever ut den funksjonaliteten man oensker aa oppnaa. En ren nat forbindelse kan varere en bra start, mener jeg.