PDA

Archiv verlassen und diese Seite im Standarddesign anzeigen : Probleme mit iptables/eigenem Script



Phate
19.08.2004, 20:23
Hi,
ich habe noch einige Schwierigkeiten mit den iptables.
Ich hab mir einen Router aufgesetzt, wie dort [1] beschrieben, der nur Masquerading für meine Rechner betreiben soll.
Also alles nach dem Howto installiert und eingerichtet, läuft wunderbar.
Das FW-Script mußte ich allerdings anpassen, und als ich schon dabei war, habe ich es geändert, weil mir die default policy von INPUT nicht gefällt und habe daher das Ziel von INPUT geändert (von ACCEPT zu DROP).

Daher zwei Fragen:

Was kann man ändern/optimieren?

Wieso kann ich nach der Ausführung des scripts vom Router aus nicht mehr aufs Netz (sowohl LAN als auch Internet) zugreifen? Die rechner aus dem LAN dagegen werden wunderbar durch den Router geleitet und alles funzt? Verstehe ich nicht wirklich...

Hier das script:



#/bin/bash

# Global variables

EXTDEV=ppp0 # External device pointing to the internet
INTDEV=eth0 # Internal device pointing to the local net
DESKTOP=192.168.1.2 # Desktop-IP
IPTABLES=/sbin/iptables # Iptables-Path

## Enable Paketforwarding and set dynamic IP

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

## Flush tables and set default policy

$IPTABLES -t filter -F INPUT
$IPTABLES -t filter -F OUTPUT
$IPTABLES -t filter -F FORWARD
$IPTABLES -t filter -P INPUT DROP
$IPTABLES -t filter -P OUTPUT ACCEPT
$IPTABLES -t filter -P FORWARD ACCEPT

## Masquerading

$IPTABLES -t nat -F POSTROUTING
$IPTABLES -t nat -A POSTROUTING -o $EXTDEV -s 192.168.1.0/24 -j MASQUERADE

## Allow all on localhost

$IPTABLES -t filter -A INPUT -i lo -s 0/0 -d 0/0 -j ACCEPT

# Define ports that should be open

$IPTABLES -t filter -A INPUT -i $EXTDEV -p tcp --dport 21 -j ACCEPT
$IPTABLES -t filter -A INPUT -i $EXTDEV -p tcp --dport 22 -j ACCEPT
$IPTABLES -t filter -A INPUT -i $EXTDEV -p tcp --dport 80 -j ACCEPT
$IPTABLES -t filter -A INPUT -i $EXTDEV -p tcp --dport 113 -j ACCEPT
$IPTABLES -t filter -A INPUT -i $EXTDEV -p tcp --dport 119 -j ACCEPT
$IPTABLES -t filter -A INPUT -i $EXTDEV -p tcp --dport 443 -j ACCEPT
$IPTABLES -t filter -A INPUT -i $EXTDEV -p udp --dport 8767 -j ACCEPT
$IPTABLES -t filter -A INPUT -i $EXTDEV -p tcp --dport 8000 -j ACCEPT
$IPTABLES -t filter -A INPUT -i $EXTDEV -p tcp --dport 45000 -j ACCEPT

$IPTABLES -t filter -A INPUT -i $INTDEV -p tcp --dport 22 -j ACCEPT

## Portforwarding

#X-Chat XDCC

$IPTABLES -t nat -A PREROUTING -i $EXTDEV -p tcp --dport 45000 -j DNAT --to-dest $DESKTOP

# Call of Duty

$IPTABLES -t nat -A PREROUTING -i $EXTDEV -p udp --dport 27960:28000 -j DNAT --to-dest $DESKTOP

# FTP

$IPTABLES -t nat -A PREROUTING -i $EXTDEV -p tcp --dport 21 -j DNAT --to-dest $DESKTOP


Vielen Dank für die Mühe!

Phate

[1]http://www.debianforum.de/wiki/?page=in+2min.+Debian+Router+mit+Firewall+in+Debia nmanier

khs
20.08.2004, 22:30
> Das FW-Script mußte ich allerdings anpassen, und als ich
> schon dabei war, habe ich es geändert, weil mir die default
> policy von INPUT nicht gefällt und habe daher das Ziel von
> INPUT geändert (von ACCEPT zu DROP).

Solange du weisst, was du da treibst, ist das durchaus eine gute Idee. Irgendwie hab ich aber den Eindruck, das ist nicht ganz der Fall... ;)
Erstens ist es nicht die feine englische Art, Pakete einfach zu DROPpen. Wenn bei dir jemand anklopft, ist es eigentlich vernuenftiger, ihm zu sagen, dass man kein Interesse hat und die Verbindung (sein Eintreten) abzulehnen. REJECT heisst das auf iptables...
Zweitens: dass du von lokal nicht ins Netz kommst, vom LAN aber raus, liegt an der Reihenfolge, mit der die Tables von iptables abgearbeitet werden.

Bitte sei nicht veraergert, wenn ich dir das sage, aber vielleicht waer ein iptables-HOWTO (da gibts sicher auch deutsche) ne gute Idee. Gar nicht bis ins letzte Detail, aber fuer die Grundlagen. Allein schon deshalb, weil du dann sehen wirst, WAS du mit iptables eigentlich alles machen kannst (Stichwort ipt_helper in Verbindung mit traffic shaping z.B.) und dir dabei sicher noch gute Ideen fuer deine Firewall-Regeln kommen. So ging es mir zumindest beim HOWTO-lesen oft... ;)

-khs

Phate
24.08.2004, 22:40
@khs:
Erstmal danke für die Antwort. :)
Iwo...verärgert, weswegen denn? Hast mir schließlich kein "RTFM" vor den Kopf geknallt. :D
Ich habe mir schon 1 Howto zum Thema zu Gemüte geführt, desweiteren die iptables-Sektion "linux in a nutshell" studiert. Deshalb frage ich ja: Weil ich mir nicht sicher bin und etwas anscheinend nicht funktioniert.

Ich frage mich nun: Was tun um die Reihenfolge zu ändern?

Gruß

qmasterrr
24.08.2004, 23:59
Also die IP-Tables sektion aus linux in a nutshell taugt in meinen augen nicht viel da fehlen einfach die praktischen beispiele :/

Ansonnsten solltest du dir ein ausführliches howto schnappen und genau analysieren was deine regeln machen und was du eigentlich beabsichtigst ...

Locke
28.09.2004, 00:04
hmm er erlaubt in deinem skript kein input des internen lans zum router.
am sinnvollsten fährste mit connections status established-related (siehe iptables manpage). input brauch kein drop, wenn kein server auf dem router lauscht und er eh nur den traffic durchschiebt. mach einfach alle auf accept und route am besten mit masquerade und established-related. eventuell noch ein paar forwards oder kernelspezialitäten für aktiv-ftp und icq und co.

Phate
28.09.2004, 00:19
Danke Locke, habs mittlerweile hinbekommen. Ich habe komplett von vorne angefangen und das Script anders strukturiert, jetzt funktioniert es zur vollsten Zufriedenheit.

Gruß

Erich Meyer
03.10.2004, 17:11
Was hältst Du denn von diesem Skript? anders als bei Dir muss es bei mir allerdings /usr/sbin/iptables heißen, aber sonst?

#:/bin/sh
# firewall-regeln
#
#================================================= =======
# Variablen
#================================================= =======
IPTABLES=/usr/sbin/iptables
#================================================= =======
# Kernel-Parameter setzen
#================================================= =======
echo "1" > /proc/sys/net/ipv4/ip_forward
echo "1" > /proc/sys/net/ipv4/ip_dynaddr
#================================================= =======
# flush aller chains
#================================================= =======
$IPTABLES -F
$IPTABLES -t nat -F
$IPTABLES -X
#================================================= =======
# input-chains
#================================================= =======
$IPTABLES -P INPUT DROP

$IPTABLES -A INPUT -i lo -j ACCEPT

$IPTABLES -A INPUT -i eth+ -j ACCEPT

$IPTABLES -A INPUT -i ppp0 -m state \
--state ESTABLISHED,RELATED -j ACCEPT

#================================================= ======
# output-chains
#================================================= ======

$IPTABLES -P OUTPUT ACCEPT

#================================================= =======
# forward-chains
#================================================= =======

$IPTABLES -P FORWARD DROP

$IPTABLES -A FORWARD -p tcp --tcp-flags SYN,RST SYN \
-j TCPMSS --clamp-mss-to-pmtu

$IPTABLES -A FORWARD -i ppp0 -m state \
--state ESTABLISHED,RELATED -j ACCEPT

$IPTABLES -A FORWARD -o ppp0 -j ACCEPT

$IPTABLES -A FORWARD -i eth+ -j ACCEPT

$IPTABLES -A FORWARD -o eth+ -j ACCEPT

#================================================= =======
# masquerading
#================================================= =======
$IPTABLES -t nat -A POSTROUTING -o ppp0 -j MASQUERADE
#================================================= =======

"eth+" bezieht sich auf alle Schnittstellen "eth0", "eth1", usw.
Ich finde es nicht bedenklich, auf kein Paket von außen zu antworten, solange man selbst keine Dienste anbietet; also $IPTABLES -P INPUT DROP zu setzen. Andernfalls würde es doch nur den Trafic erhöhen.

grüß Dich
Erich

Psimon
29.01.2006, 13:39
wenigstens sind wir uns alle einig und verwenden devices (eth0,eth1,.. dsl0,ppp0..) als variablen unserer rules. :)


input brauch kein drop, wenn kein server auf dem router lauscht und er eh nur den traffic durchschiebt. mach einfach alle auf accept und route am besten mit masquerade und established-related. eventuell noch ein paar forwards oder kernelspezialitäten für aktiv-ftp und icq und co.

das klingt mir ja fast so wie:
"wenn ich den default der forward chain auf ACCEPT setze, kann mir bei meinen win maschinen im LAN nichts passieren weil im prerouting kein nat eintrag in den ipheader gemacht wurde und die packete somit eh nicht den richtigen weg finden".