Kleines großes Routing-Problem

tk1908

Nabend,
ich versuche mich aktuell an ner Änderung meines Routing-Setups.

Aktuell:

DSL -> Fritzbox -> Homeserver -> Embedded Kiste mit pfsense -> Switch -> Rechner.

Dabei hängt der Homeserver mit dem /30er Netz an der pfsense an em0 (WAN-Port).

Netze:
Transportnetz (DMZ): 10.0.0.0/30
LAN: 10.24.0.0/16 (em1 an pfsense)
WLAN: 172.16.1.0/24 (ath0 an pfsense)

In der DMZ hängen nur die Router (Homeserer und pfsense).
Der Homeserver kommt ins Inet. Die pfsense Box kann den Homeserver pingen, kommt aber nicht raus. Regeln stehen INPUT auf DROP, aber Output sollte alles auf ACCEPT stehen.
DHCP auf Homeserver ist aus, Adressen sind statisch hinterlegt.

Jemand ne Idee?

Viele Grüße

tk

mrshadowtux

Du musst Antworen anhand des States erkennen und rein lassen. Denn mit deiner "alles droppen" Regel droppst du auch die.

In iptables wäre die Lösung:
iptables -A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT

Schau mal, dass du bei pfSense Pakete dieser beiden States reinläßt, das sind die Antworten.

Drop ist übrigens unsauber, da es Timeouts verursacht. Hier solltest du zu Rejects wechseln. Ich weiß allerdings nicht, wo genau das bei pfSense ist.

tk1908

Zitat von mrshadowtux

Du musst Antworen anhand des States erkennen und rein lassen. Denn mit deiner "alles droppen" Regel droppst du auch die.
In iptables wäre die Lösung:
iptables -A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
Schau mal, dass du bei pfSense Pakete dieser beiden States reinläßt, das sind die Antworten.
Drop ist übrigens unsauber, da es Timeouts verursacht. Hier solltest du zu Rejects wechseln. Ich weiß allerdings nicht, wo genau das bei pfSense ist.

Sollte er das nicht automatisch machen?

mrshadowtux

Ich kenne deine Konfiguration nicht. Wenn du nur sagt "drop mal alles weg", macht er genau das. Du musst ihm dann schon sagen, dass er ne Ausnahme für Pakete mit bestimmten States macehn soll. Ist halt ne Stateful Firewall.

CHRiSNEW

Wie sehen denn die iptables-Regeln aus und was sagt ip r s auf den jeweiligen Routern?

IPv6 ist bei sowas angenehmer. Zumindest ist das meine Erfahrung. Man setzt die Routen und die jeweiligen Präfixe und it just werks™

mrshadowtux

pfSense nutzt pf statt netfilter. Dem entsprechend gibt es kein iptables dort. Auch ip wird es dort nicht geben, ifconfig und route wären dort von Nöten, da FreeBSD.

Aber am besten ist, du zeigst einfach mal alle gesetzten Regeln und wir schauen weiter.

tk1908

Zitat von mrshadowtux

pfSense nutzt pf statt netfilter. Dem entsprechend gibt es kein iptables dort. Auch ip wird es dort nicht geben, ifconfig und route wären dort von Nöten, da FreeBSD.
Aber am besten ist, du zeigst einfach mal alle gesetzten Regeln und wir schauen weiter.

Ich hab jetz erstmal nen Workaround geschaffen. Homeserver stellt per DHCP das 10.0.0.0/30er Netz bereit. Mit ner statischen IP muss ichs die Tage nochmal ausprobieren.

**Alpha**

Zitat von mrshadowtux

Drop ist übrigens unsauber, da es Timeouts verursacht. Hier solltest du zu Rejects wechseln. Ich weiß allerdings nicht, wo genau das bei pfSense ist.

Unsauber ist relativ. Gerade im Router würde ich ins Internet garnicht antworten. Wozu? Ich würde ankommenden Müll einfach verwerfen, wenn ich daran kein weiteres Interesse habe. Ausnahme sehe ich hier nur bei ICMPs.

mrshadowtux

Weil du sonst Timeouts verursachst. Das wirkt auf User verwirrend, da sie warten und warten und warten. Aus Sicht eines Angreifers sieht es dann so aus, als sei deine Kiste überlastet. Resultat kann dann sein, dass er es erneut probiert.

Besser ist hier Reject, was das Paket ebenso verwirft, ihm dann aber über ICMP unmissverständlich klar macht, dass er hier nicht weiter kommr ("Connection Refused", auch ein paar andere Fehler sind wählbar)

Gibt auch ne RFC, in der ganz klar gesagt wird, dass Reject der richtige Weg ist. Muss ich mal raussuchen.

**Alpha**

Zitat von mrshadowtux

Weil du sonst Timeouts verursachst. Das wirkt auf User verwirrend, da sie warten und warten und warten. Aus Sicht eines Angreifers sieht es dann so aus, als sei deine Kiste überlastet. Resultat kann dann sein, dass er es erneut probiert.
Besser ist hier Reject, was das Paket ebenso verwirft, ihm dann aber über ICMP unmissverständlich klar macht, dass er hier nicht weiter kommr ("Connection Refused", auch ein paar andere Fehler sind wählbar)
Gibt auch ne RFC, in der ganz klar gesagt wird, dass Reject der richtige Weg ist. Muss ich mal raussuchen.

Ich rede vom Home Router. Vor genau hat da der User Timeouts, auf welche er wartet? Wie ich sagte, für ICMP sehe ich das gerechtfertigt, dass man REJECT nutzt. Sonst nicht. Warum sollte mein Home Router auf irgendwelches Rauschen im Internet noch antworten? Das macht doch keinen Sinn.

mrshadowtux

Um besagten Angreifern klar zu machen, dass es dort nichts gibt auf dem jeweiligen Port. Sonst probieren die es später erneut (Paket ging ja verloren, eventuell ist das ielsystem ja nur ausgelastet).

Zumal Drop nicht RFC-Konform ist.

Zitat dazu aus dem Arch-Wiki: We use REJECT rather than DROP here, because RFC 1122 3.3.8 requires hosts return ICMP errors whenever possible, instead of dropping packets

Sehr gute Zusammenfassung: http://www.chiark.greenend.org.uk/~peterb/network/drop-vs-reject

**DosAmp**

Zitat von mrshadowtux

Weil du sonst Timeouts verursachst. Das wirkt auf User verwirrend, da sie warten und warten und warten. Aus Sicht eines Angreifers sieht es dann so aus, als sei deine Kiste überlastet. Resultat kann dann sein, dass er es erneut probiert.

Auf einen Dienst, dessen Existenz Benutzern nicht vertraut sein muss, verbindet sich auch keiner. Und Angreifer sind im Internet ohnehin vollständig automatisiert (Portscans, Botnets), sie werden z. B. trotz allem fortfahren, deinen Server stumpf mit SSH-/RDP-Anfragen zu behämmern.
Es spricht nichts dagegen, Verbindungen von „feindlichen“ Clients zu droppen anstatt zurückzuweisen, da es sie im besten Falle wie beschrieben ausbremst. Das echte Internet hält sich auch nicht immer an deine gedruckten Regelwerke.

Zitat von mrshadowtux

Besser ist hier Reject, was das Paket ebenso verwirft, ihm dann aber über ICMP unmissverständlich klar macht, dass er hier nicht weiter kommr ("Connection Refused", auch ein paar andere Fehler sind wählbar)

Du denkst jetzt an andere Protokolle wie UDP und die ICMP-Antwort Destination Unreachable bzw. Port Unreachable. Bei TCP würgt der Netzwerk-Stack den einkommenden Verbindungsversuch einfach per RST ab, außer man definiert in iptables explizit --reject-with icmp-port-unreachable. Das wäre dann aber bereits wieder deutlich unterscheidbares Verhalten zu einem gar nicht geöffneten Port.

mrshadowtux

Die meisten Angreiferscripte gehen eben anders vor. Sie führen eine Art Blacklist mit IP/Port-Kombis wo sie nicht reinkamen (Da landet man dann bei nem Reject direkt). Bei anderen IP/Port-Kombis probieren sie weiter für zig mal, bevor sie aufgeben.

Standardmäßig nutzt iptables ein Port Unreachable. Man kann aber auch einen TCP Reset übers Reject senden. Das ist dann auch absolut regelkonform.

Die RFCs haben schon ihre Gründe, wer sagt die seien unnötig hat das Internet nicht so recht verstanden.

CHRiSNEW

Zitat von mrshadowtux

Die meisten Angreiferscripte gehen eben anders vor. Sie führen eine Art Blacklist mit IP/Port-Kombis wo sie nicht reinkamen (Da landet man dann bei nem Reject direkt).

Naja, schön wär's. Ich sehe zu oft die gleichen Idioten mehrmals antanzen. Egal, was man antwortet.

**Alpha**

Zitat von CHRiSNEW

Naja, schön wär's. Ich sehe zu oft die gleichen Idioten mehrmals antanzen. Egal, was man antwortet.

Genau meine Erfahrung..

tk1908

Hier hat soch jetzt noch ein Problem ergeben. Die Konstellation ist die selbe wie oben beschrieben. Allerdings kann ich jetzt keine NFS-Shares mehr von 10.0.0.1 mounten. (Zumindest wenn die Anfrage aus 10.24.0.0/16 oder 172.16.1.0/24 kommt.)

Routen auf 10.0.0.1 sehen so aus:

Code

root@beer:/home/tkoehler# ip route
default via 192.168.178.1 dev wlan0
10.0.0.0/30 dev eth0  proto kernel  scope link  src 10.0.0.1
10.24.0.0/16 via 10.0.0.2 dev eth0
172.16.1.0/24 via 10.0.0.2 dev eth0
192.168.178.0/24 dev wlan0  proto kernel  scope link  src 192.168.178.22
root@beer:/home/tkoehler#

iptables:

Code

root@beer:/home/tkoehler# iptables -L
Chain INPUT (policy DROP)
target     prot opt source               destination
ACCEPT     all  --  anywhere             anywhere             state RELATED,ESTABLISHED
ACCEPT     icmp --  anywhere             anywhere
ACCEPT     all  --  anywhere             anywhere
ACCEPT     all  --  anywhere             anywhere
ACCEPT     all  --  anywhere             anywhere


Chain FORWARD (policy ACCEPT)
target     prot opt source               destination


Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination
ACCEPT     all  --  anywhere             anywhere
ACCEPT     all  --  anywhere             anywhere
ACCEPT     all  --  anywhere             anywhere
root@beer:/home/tkoehler#




echo Firewall wird gestartet.
# Erstmal die alten Regeln rauswerfen
iptables -F
iptables -X


# ...und Forwarding aktivieren
echo 1 > /proc/sys/net/ipv4/ip_forward
# Routing/NAT
iptables -t nat -A POSTROUTING -o $TARGET -d 0.0.0.0/0 -j MASQUERADE


# Antworten Auf Paketanfragen erlauben (Kann man prima am State nachschauen)
iptables -A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT


# Eingehende Pings erlauben
iptables -A INPUT -p icmp -j ACCEPT
# Eingehendes ssh erlauben
iptables -A INPUT -p tcp -m --dport 22 -j ACCEPT


# Eingehendes nfs erlauben
iptables -A INPUT -p tcp -m --dport 2049 -j ACCEPT
# Eingehendes dns erlauben
iptables -A INPUT -p udp -m --dport 53 -j ACCEPT
# Auf Loopback darf alles rein und raus
iptables -A INPUT -i lo -j ACCEPT
iptables -A OUTPUT -o lo -j ACCEPT


 # Auf dem Quellinterface ist alles erlaubt
iptables -A INPUT -i $SOURCE -j ACCEPT
iptables -A OUTPUT -o $SOURCE -j ACCEPT
# Auf dem Zielinterface ist auch alles erlaubt
iptables -A INPUT -i $TARGET -j ACCEPT
iptables -A OUTPUT -o $TARGET -j ACCEPT
 # Policies setzen
 iptables -P INPUT DROP

Alles anzeigen

NFS-Exports:

Code

/data/save      10.24.0.0/16(rw,no_subtree_check)
/data/save      172.16.1.0/24(rw,no_subtree_check)
/data/save      192.168.178.31(rw,all_squash,anonuid=1000,anongid=1000) #NFS-Share für N900
/data/nfs/grml32 10.18.1.1/16(ro)
/data/nfs/grml64 10.18.1.1/16(ro)

Vielen Dank schon mal.

Zitat von tk1908

Hier hat soch jetzt noch ein Problem ergeben. Die Konstellation ist die selbe wie oben beschrieben. Allerdings kann ich jetzt keine NFS-Shares mehr von 10.0.0.1 mounten. (Zumindest wenn die Anfrage aus 10.24.0.0/16 oder 172.16.1.0/24 kommt.)

Routen auf 10.0.0.1 sehen so aus:

Code

root@beer:/home/tkoehler# ip route
default via 192.168.178.1 dev wlan0
10.0.0.0/30 dev eth0  proto kernel  scope link  src 10.0.0.1
10.24.0.0/16 via 10.0.0.2 dev eth0
172.16.1.0/24 via 10.0.0.2 dev eth0
192.168.178.0/24 dev wlan0  proto kernel  scope link  src 192.168.178.22
root@beer:/home/tkoehler#

iptables:

Code

root@beer:/home/tkoehler# iptables -L
Chain INPUT (policy DROP)
target     prot opt source               destination
ACCEPT     all  --  anywhere             anywhere             state RELATED,ESTABLISHED
ACCEPT     icmp --  anywhere             anywhere
ACCEPT     all  --  anywhere             anywhere
ACCEPT     all  --  anywhere             anywhere
ACCEPT     all  --  anywhere             anywhere


Chain FORWARD (policy ACCEPT)
target     prot opt source               destination


Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination
ACCEPT     all  --  anywhere             anywhere
ACCEPT     all  --  anywhere             anywhere
ACCEPT     all  --  anywhere             anywhere
root@beer:/home/tkoehler#




echo Firewall wird gestartet.
# Erstmal die alten Regeln rauswerfen
iptables -F
iptables -X


# ...und Forwarding aktivieren
echo 1 > /proc/sys/net/ipv4/ip_forward
# Routing/NAT
iptables -t nat -A POSTROUTING -o $TARGET -d 0.0.0.0/0 -j MASQUERADE


# Antworten Auf Paketanfragen erlauben (Kann man prima am State nachschauen)
iptables -A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT


# Eingehende Pings erlauben
iptables -A INPUT -p icmp -j ACCEPT
# Eingehendes ssh erlauben
iptables -A INPUT -p tcp -m --dport 22 -j ACCEPT


# Eingehendes nfs erlauben
iptables -A INPUT -p tcp -m --dport 2049 -j ACCEPT
# Eingehendes dns erlauben
iptables -A INPUT -p udp -m --dport 53 -j ACCEPT
# Auf Loopback darf alles rein und raus
iptables -A INPUT -i lo -j ACCEPT
iptables -A OUTPUT -o lo -j ACCEPT


 # Auf dem Quellinterface ist alles erlaubt
iptables -A INPUT -i $SOURCE -j ACCEPT
iptables -A OUTPUT -o $SOURCE -j ACCEPT
# Auf dem Zielinterface ist auch alles erlaubt
iptables -A INPUT -i $TARGET -j ACCEPT
iptables -A OUTPUT -o $TARGET -j ACCEPT
 # Policies setzen
 iptables -P INPUT DROP

Alles anzeigen

NFS-Exports:

Code

/data/save      10.24.0.0/16(rw,no_subtree_check)
/data/save      172.16.1.0/24(rw,no_subtree_check)
/data/save      192.168.178.31(rw,all_squash,anonuid=1000,anongid=1000) #NFS-Share für N900
/data/nfs/grml32 10.18.1.1/16(ro)
/data/nfs/grml64 10.18.1.1/16(ro)

Vielen Dank schon mal.

Kleiner EDIT:

Als Fehlermeldung bekomme ich:
"mount.nfs: access denied by server while mounting beer:/data/save"

tk1908

Zitat von tk1908

Hier hat soch jetzt noch ein Problem ergeben. Die Konstellation ist die selbe wie oben beschrieben. Allerdings kann ich jetzt keine NFS-Shares mehr von 10.0.0.1 mounten. (Zumindest wenn die Anfrage aus 10.24.0.0/16 oder 172.16.1.0/24 kommt.)

Routen auf 10.0.0.1 sehen so aus:

Code

root@beer:/home/tkoehler# ip route
default via 192.168.178.1 dev wlan0
10.0.0.0/30 dev eth0  proto kernel  scope link  src 10.0.0.1
10.24.0.0/16 via 10.0.0.2 dev eth0
172.16.1.0/24 via 10.0.0.2 dev eth0
192.168.178.0/24 dev wlan0  proto kernel  scope link  src 192.168.178.22
root@beer:/home/tkoehler#

iptables:

Code

root@beer:/home/tkoehler# iptables -L
Chain INPUT (policy DROP)
target     prot opt source               destination
ACCEPT     all  --  anywhere             anywhere             state RELATED,ESTABLISHED
ACCEPT     icmp --  anywhere             anywhere
ACCEPT     all  --  anywhere             anywhere
ACCEPT     all  --  anywhere             anywhere
ACCEPT     all  --  anywhere             anywhere


Chain FORWARD (policy ACCEPT)
target     prot opt source               destination


Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination
ACCEPT     all  --  anywhere             anywhere
ACCEPT     all  --  anywhere             anywhere
ACCEPT     all  --  anywhere             anywhere
root@beer:/home/tkoehler#




echo Firewall wird gestartet.
# Erstmal die alten Regeln rauswerfen
iptables -F
iptables -X


# ...und Forwarding aktivieren
echo 1 > /proc/sys/net/ipv4/ip_forward
# Routing/NAT
iptables -t nat -A POSTROUTING -o $TARGET -d 0.0.0.0/0 -j MASQUERADE


# Antworten Auf Paketanfragen erlauben (Kann man prima am State nachschauen)
iptables -A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT


# Eingehende Pings erlauben
iptables -A INPUT -p icmp -j ACCEPT
# Eingehendes ssh erlauben
iptables -A INPUT -p tcp -m --dport 22 -j ACCEPT


# Eingehendes nfs erlauben
iptables -A INPUT -p tcp -m --dport 2049 -j ACCEPT
# Eingehendes dns erlauben
iptables -A INPUT -p udp -m --dport 53 -j ACCEPT
# Auf Loopback darf alles rein und raus
iptables -A INPUT -i lo -j ACCEPT
iptables -A OUTPUT -o lo -j ACCEPT


 # Auf dem Quellinterface ist alles erlaubt
iptables -A INPUT -i $SOURCE -j ACCEPT
iptables -A OUTPUT -o $SOURCE -j ACCEPT
# Auf dem Zielinterface ist auch alles erlaubt
iptables -A INPUT -i $TARGET -j ACCEPT
iptables -A OUTPUT -o $TARGET -j ACCEPT
 # Policies setzen
 iptables -P INPUT DROP

Alles anzeigen

NFS-Exports:

Code

/data/save      10.24.0.0/16(rw,no_subtree_check)
/data/save      172.16.1.0/24(rw,no_subtree_check)
/data/save      192.168.178.31(rw,all_squash,anonuid=1000,anongid=1000) #NFS-Share für N900
/data/nfs/grml32 10.18.1.1/16(ro)
/data/nfs/grml64 10.18.1.1/16(ro)

Vielen Dank schon mal.

Kleiner EDIT:

Als Fehlermeldung bekomme ich:
"mount.nfs: access denied by server while mounting beer:/data/save"

Alles anzeigen

Keiner ne Idee?

CHRiSNEW

Welche IP-Adresse kommt denn am NFS Server an? Ich würde fast vermuten, dass irgendwie 10.0.0.1 aufschlägt.

tk1908

Zitat von CHRiSNEW

Welche IP-Adresse kommt denn am NFS Server an? Ich würde fast vermuten, dass irgendwie 10.0.0.1 aufschlägt.

Rein von der Logik müsste 10.0.0.2 ankommen. Ich sniffe heute Abend mal den Traffic mit tcpdump.

CHRiSNEW

Wenn der von 10.0.0.2 ankommt, dann ist das klar, dass ein Access Denied fliegt.

Du müsstest noch

Code

/data/save      10.0.0.2/32(rw,no_subtree_check)

hinzufügen

Kleines großes Routing-Problem

Jetzt mitmachen!

Benutzer online in diesem Thema