[iptables] Gaat dit werken? - Linux en overige clients

donderdag 13 december 2001 23:09

Acties:

Topicstarter

Owke, simpel netwerkje linuxbakkie met kabelmodem die ook wat servertjes daait (irc, mail, web)die inet moet routen voor het netwerk erachter (192.168.0.0)

rc.firewall

code:

#!/bin/bash
#Firewall and NAT/MASQ scrippie versie 0.0alpha

#waar hebben we iptables verstopt?
iptables="/usr/sbin/iptables"

#nice line
echo "***                          ***"

#Interne netwerk interface
int_iface="eth0"
int_netw="192.168.0.0/24"
int_addr="192.168.0.3/24"
universe=".0.0/0"
echo "***   Internal interface: $int_iface     ***"
echo "***   Internal address: $int_addr ***"
echo "***   Internal network: $int_netw ***"

#Externe (internet) interface
ext_iface="eth1"
ext_addr=`/sbin/ifconfig $ext_iface|grep 'inet addr'|awk '{print $2}'|sed -e 's/.*://'`
echo "***   External interface: $ext_iface     ***"
echo "***   External address: $ext_addr    ***"

#nice line
echo "***                          ***"

echo "***   Loading modules:             ***"

/sbin/modprobe ip_tables
echo "***   Loading module: ip_tables     ***"

/sbin/modprobe ip_conntrack
echo "***   Loading module: ip_conntrack     ***"

/sbin/modprobe ip_conntrack_ftp
echo "***   Loading module: ip_conntrack_ftp ***"

/sbin/modprobe ip_conntrack_irc
echo "***   Loading module: ip_conntrack_irc ***"

/sbin/modprobe iptable_nat
echo "***   Loading module: iptable_nat ***"

echo "***    Done                   ***"

#nice line
echo "***                          ***"

#enable ipv4 forwarding
echo "***   Enabling ipv4 Forwarding       ***"
echo "1">/proc/sys/net/ipv4/ip_forward

#enable dynamic address
echo "***   Enabling ipv4 Dynaddr       ***"
echo "1">/proc/sys/net/ipv4/ip_dynaddr

#nice line
echo "***                          ***"
#Setting IP forwarding & Masq
echo "***   Setting default policies       ***"
echo "***    Input:   DROP           ***"
echo "***    Output:  DROP           ***"
echo "***    Forward: DROP           ***"

$iptables -P INPUT DROP
$iptables -F INPUT
$iptables -P OUTPUT DROP
$iptables -F INPUT
$iptables -P FORWARD DROP
$iptables -F INPUT
$iptables -F -t nat

#nice line
echo "***                          ***"

echo "***   Deleting existing chains       ***"
$iptables -X

#nice line
echo "***                          ***"

echo "***   Resetting counters         ***"
$iptables -Z

#nice line
echo "***                          ***"

echo "***   Creating DROP chain       ***"
#log alles wat binnenkomt en rejecten
$iptables -N drop-and-log-it
$iptables -A drop-and-log-it -j LOG --log-level info
$iptables -A drop-and-log-it -j REJECT

#nice line
echo "***                          ***"

echo "***   Loading INPUT rulesets       ***"

#loopback interface mag alles inputten
$iptables -A INPUT -i lo -s $universe -d $universe -j ACCEPT

#lokale interface, lokaal netwerk, overal heen valid
$iptables -A INPUT -i $int_iface -s $int_netw -d $universe -j ACCEPT

#externe interface, lokaal netwerk, overal heen sturen naar drop-and-log-it chain
$iptables -A INPUT -i $ext_iface -s $int_netw -d $universe -j drop-and-log-it

#externe interface, van ieder addres, naar ext_ip, ICMP packet, valid
$iptables -A INPUT -i $ext_iface -p ICMP -s $universe -d $ext_addr -j ACCEPT

#MASQ verkeer moet er weer inkunnen
$iptables -A INPUT -i $ext_iface -s $universe -d $ext_addr -m state --state ESTABLISHED,RELATED -j ACCEPT

#poort 80 22 6667 en 110 openzetten voor ext iface
echo "***    Allowing trafic on port 80 ***"
#www
$iptables -A INPUT -i $ext_iface -s $universe -d $ext_addr -p tcp --dport 80 -j ACCEPT
$iptables -A INPUT -i $ext_iface -s $universe -d $ext_addr -p udp --dport 80 -j ACCEPT

echo "***    Allowing trafic on port 22 ***"
#SSH
$iptables -A INPUT -i $ext_iface -s $universe -d $ext_addr -p tcp --dport 22 -j ACCEPT

echo "***    Allowing trafic on port 6667    ***"
#IRC
$iptables -A INPUT -i $ext_iface -s $universe -d $ext_addr -p tcp --dport 6667 -j ACCEPT
$iptables -A INPUT -i $ext_iface -s $universe -d $ext_addr -p udp --dport 6667 -j ACCEPT

echo "***    Allowing trafic on port 110     ***"
#Mail
$iptables -A INPUT -i $ext_iface -s $universe -d $ext_addr -p tcp --dport 110 -j ACCEPT


#Regeltje die alles wat niet matched logged en reject
$iptables -A INPUT -i $ext_iface -s $universe -d $universe -j drop-and-log-it

echo "***    Done                   ***"

#nice line
echo "***                          ***"

echo "***   Loading OUTPUT rulesets     ***"

#loopback iface mag uiteraard
$iptables -A OUTPUT -o lo -s $universe -d $universe -j ACCEPT

#naar interne interface van externe iface, naar lokaalnet (das wel makkelijk :))
$iptables -A OUTPUT -o $int_iface -s $ext_addr -d $int_netw -j ACCEPT

#van interne interface naar interne interface, naar lokaalnet
$iptables -A OUTPUT -o $int_iface -s $int_addr -d $int_netw -j ACCEPT

#Externe interface, naar lokaalnet das niet goe
$iptables -A OUTPUT -o $ext_iface -s $universe -d $int_netw -j drop-and-log-it

#Externe interface mag alles verzenden (niet met lokaal doeladress, zie boven) en alleen met ons ext_ipaddress als source
$iptables -A OUTPUT -o $ext_iface -s $ext_addr -d $universe -j ACCEPT

#Regeltje die de rest trashed (dus niet met ons externe ip al source
$iptables -A OUTPUT -o $ext_iface -s $universe -d $universe -j drop-and-log-it

echo "***    Done                   ***"
#nice line
echo "***                          ***"

echo "***   Loading FORWARD (MASQ)rulesets   ***"

#alleen bestaande connecties naar binnen toe
$iptables -A FORWARD -i $ext_iface -o $int_iface -m state --state ESTABLISHED,RELATED -j ACCEPT

#van interne iface naar de externe toe
$iptables -A FORWARD -i $int_iface -o $ext_iface -j ACCEPT

#de rest trashen en loggen
$iptables -A FORWARD -j drop-and-log-it

echo "***    Done                   ***"
#nice line
echo "***                          ***"
echo "***+++---    Vuurmuur gestart  ---+++***"

Aangezien dit script voor iemand anders is en ik het hier niet kan testen zou ik willen vragen of iemand hier wat fouten in ziet...

vrijdag 14 december 2001 00:22

Acties:

Verwijderd

Ziet er wel goed uit.
Aleen wel een paar opmerkingen.

code:

1 2	int_addr="192.168.0.3/24" universe=".0.0/0"

Daar bedoel je dus het interne adres mee. Ofwel een netmask van 32

Verder vind ik persoonlijk een universe van 0.0.0.0/0 netter (ik weet niet of bovenstaande mag)

Dus:

code:

1 2	int_addr="192.168.0.3/32" universe="0.0.0.0/0"

Bij de output rules valt me ook meteen iets op:

code:

1 2	#naar interne interface van externe iface, naar lokaalnet (das wel makkelijk :)) $iptables -A OUTPUT -o $int_iface -s $ext_addr -d $int_netw -j ACCEPT

Hoe kan je externe adres naar buiten gaan over je interne nic?
De output regel betekent dat het verkeer vanaf de server zelf afkomstig is. Als het naar je interne netwerk moet, dan gaat dit automatisch over je interne nic. Ofwel het source address zal nooit en te nimmer je external address zijn.
De -s $ext_addr zal dus nooit voor true zorgen.
De daarop volgende regel zorgt al voor toegang vanaf de server naar je lokale net. Dus heel deze regel kan geschrapt worden.

Als laatste valt me nog op, dat je nergens je verkeer masqueraded

Is wel handig om vanaf de clients internet op te kunnen komen.

code:

1	iptables -t nat -A POSTROUTING -s $int_netw -d $universe -o $ext_iface -j MASQUERADE

Voor de rest zie ik eigenlijk niet veel verkeerds of missende dingen, maar ja ik kan er zo een paar gemist hebben he

vrijdag 14 december 2001 18:11

Acties:

_-= Erikje =-_

Topicstarter

universe --> tiepfout

Dit komt uit de ipmasq howto nl, owke, ff die regel eruit gooien en die masq regel nog ff toevoegen...

kloppen de regels voor poort 22 80 110 en 6667 wel? is van belang omdat het ding ook als webserver/irc ingezet gaan worden. (ssh voor beheer, 110 voor cron job mailtjes)

zaterdag 15 december 2001 10:35

Acties:

JayTaph

Portability is for canoes.

Je input-chain heeft niks meer van doen met forwarding. Je gaat statefull controleren of een incoming verbinding mag, maar je gaat niet statefull uitsturen. In principe hoeft dit dus niet (en kost je alleen maar state-connections).

Verder ACCEPT je alles klakkeloos. Ik zoveel mogelijk via connection tracking gaan werken (da's an sich veiliger, en straks voor ftp en dcc ook broodnodig).

Yo dawg, I heard you like posts so I posted below your post so you can post again.

zaterdag 15 december 2001 18:00

Acties:

Verwijderd

Op vrijdag 14 december 2001 18:11 schreef _-= Erikje =-_ het volgende:
universe --> tiepfout

Dit komt uit de ipmasq howto nl, owke, ff die regel eruit gooien en die masq regel nog ff toevoegen...

kloppen de regels voor poort 22 80 110 en 6667 wel? is van belang omdat het ding ook als webserver/irc ingezet gaan worden. (ssh voor beheer, 110 voor cron job mailtjes)

6667 hoeft niet perse open.. als je de ip_nat_irc module maar hebt gecompiled en geladen hebt met:

code:

1	/sbin/modprobe ip_nat_irc port=6667

zaterdag 15 december 2001 18:16

Acties:

Verwijderd

Op zaterdag 15 december 2001 10:35 schreef JayTaph het volgende:
Je input-chain heeft niks meer van doen met forwarding.

Klopt, de omschrijving die erbij staat klopt niet

Alleen die regel heb je toch echt wel nodig om op de server zelf iets te kunnen doen.

Je gaat statefull controleren of een incoming verbinding mag, maar je gaat niet statefull uitsturen. In principe hoeft dit dus niet (en kost je alleen maar state-connections).

Die zijn best wel verwaarloosbaar. Waarom je perse statefull INPUT met statefull OUTPUT moet combineren ontgaat mij even. Dit is wel degegelijk een oplossing, die beter is dan een stateless oplossing (hoewel ik inderdaad zelf wel een statefull OUTPUT zou maken).

Verder ACCEPT je alles klakkeloos. Ik zoveel mogelijk via connection tracking gaan werken (da's an sich veiliger, en straks voor ftp en dcc ook broodnodig).

Policies staan toch echt allemaal op DROP

zaterdag 15 december 2001 19:06

Acties:

JayTaph

Portability is for canoes.

Op zaterdag 15 december 2001 18:16 schreef nelske het volgende:

[..]

Klopt, de omschrijving die erbij staat klopt niet
Alleen die regel heb je toch echt wel nodig om op de server zelf iets te kunnen doen.

Jah, ik heb voor de gein eventjes de regel gelezen ipv alleen het commentaar

. Het was meer algemene info ten opzichte van ipchains.

[..]

Die zijn best wel verwaarloosbaar. Waarom je perse statefull INPUT met statefull OUTPUT moet combineren ontgaat mij even. Dit is wel degegelijk een oplossing, die beter is dan een stateless oplossing (hoewel ik inderdaad zelf wel een statefull OUTPUT zou maken).
[..]

Bij de input-rule wordt er gekeken naar statefull connections, maar deze worden helemaal nooit aangemaakt in de output chain (toch?) Waarom zou de stack dan elke keer door de state-tabellen heen moeten lopen om te kijken of er een connection is, waarvan je al weet dat die niet bestaat? (volgens mij zeg ik het toch goed, verbeter maar als het niet zo is

)

Policies staan toch echt allemaal op DROP

Ja, maar ik doelde op het feit dat alles zonder te kijken naar illegal flags en dergelijke wordt geaccepteerd (-A FORWARD -I intern -O extern -j ACCEPT).
Ik zou gewoon alleen doorlaten als een connectie statefull is (established, related), wat er ook gedaan wordt, maar de forward-output rules iets aanscherpen (bv, state new geven aan sync-paketten, geen fragments zonder tracking doorlaten etc). ICMP en UDP zou ik ook niet zo klakkeloos doorlaten. Ieder zijn eigen manier natuurlijk, maar volgens mij is dat nog een stukje veiliger.

Yo dawg, I heard you like posts so I posted below your post so you can post again.

zondag 16 december 2001 13:47

Acties:

Verwijderd

Op zaterdag 15 december 2001 19:06 schreef JayTaph het volgende:

[..]

Jah, ik heb voor de gein eventjes de regel gelezen ipv alleen het commentaar . Het was meer algemene info ten opzichte van ipchains.

Ghehe

/me leest het net andersom

Geen commentaar bekijken en als ik iets niet snap wel commentaar bekijken.

Bij de input-rule wordt er gekeken naar statefull connections, maar deze worden helemaal nooit aangemaakt in de output chain (toch?) Waarom zou de stack dan elke keer door de state-tabellen heen moeten lopen om te kijken of er een connection is, waarvan je al weet dat die niet bestaat? (volgens mij zeg ik het toch goed, verbeter maar als het niet zo is )

Hmzz, das eigenlijk wel een goede

Bij mijn weten is het zo, dat de state altijd bijgehouden wordt door iptables, ongeacht of je nu in meerdere chains erop controleert.
Als het goed is moet bevenstaande dus ook gewoon werken.
/me gaat het eens nakijken, als hij eraan denkt

Ja, maar ik doelde op het feit dat alles zonder te kijken naar illegal flags en dergelijke wordt geaccepteerd (-A FORWARD -I intern -O extern -j ACCEPT).
Ik zou gewoon alleen doorlaten als een connectie statefull is (established, related), wat er ook gedaan wordt, maar de forward-output rules iets aanscherpen (bv, state new geven aan sync-paketten, geen fragments zonder tracking doorlaten etc). ICMP en UDP zou ik ook niet zo klakkeloos doorlaten. Ieder zijn eigen manier natuurlijk, maar volgens mij is dat nog een stukje veiliger.

Yupz

Daar heb je helemaal gelijk in. Een beetje verfijning daarin zou wel prettig zijn ja

zondag 16 december 2001 18:37

Acties:

_-= Erikje =-_

Topicstarter

en hoe zou ik die kunnen aanscherpen dan?