Neue Antwort schreiben 
 
Themabewertung:
  • 0 Bewertung(en) - 0 im Durchschnitt
  • 1
  • 2
  • 3
  • 4
  • 5
Kleines großes Routing-Problem
mrshadowtux
Unregistered

 
Beitrag #11
RE: Kleines großes Routing-Problem
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/~peter...-vs-reject
08.09.2015 10:07
Diese Nachricht in einer Antwort zitieren
DosAmp Offline
Anderes Zeigegerät

Beiträge: 12.219
Registriert seit: Jul 2008
Beitrag #12
RE: Kleines großes Routing-Problem
(08.09.2015 09:54)mrshadowtux schrieb:  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.

(08.09.2015 09:54)mrshadowtux schrieb:  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.

CCITTグループ4またはZIP圧縮のモノクロ300dpiで最高の再現性
(Dieser Beitrag wurde zuletzt bearbeitet: 08.09.2015 10:16 von DosAmp.)
08.09.2015 10:15
Webseite des Benutzers besuchen Alle Beiträge dieses Benutzers finden Diese Nachricht in einer Antwort zitieren
mrshadowtux
Unregistered

 
Beitrag #13
RE: Kleines großes Routing-Problem
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.
08.09.2015 10:20
Diese Nachricht in einer Antwort zitieren
CHRiSNEW Offline
Internetblasensammler

Beiträge: 2.864
Registriert seit: Jul 2008
Beitrag #14
RE: Kleines großes Routing-Problem
(08.09.2015 10:20)mrshadowtux schrieb:  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.

08.09.2015 10:51
Alle Beiträge dieses Benutzers finden Diese Nachricht in einer Antwort zitieren
Alpha Offline
Oskar

Beiträge: 16.344
Registriert seit: Jan 2009
Beitrag #15
RE: Kleines großes Routing-Problem
(08.09.2015 10:51)CHRiSNEW schrieb:  
(08.09.2015 10:20)mrshadowtux schrieb:  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.

Genau meine Erfahrung..

Mark IV Style Motherfucker!
08.09.2015 10:54
Alle Beiträge dieses Benutzers finden Diese Nachricht in einer Antwort zitieren
tk1908 Offline
Unixer

Beiträge: 7.353
Registriert seit: Apr 2009
Beitrag #16
RE: Kleines großes Routing-Problem
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

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.

(12.09.2015 23:11)tk1908 schrieb:  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

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"


Angehängte Datei(en) Thumbnail(s)
           

[Bild: Rz3JNLI.gif]
Meine Beiträge stehen unter der MIT-Lizenz:D

(09.04.2016 13:26)tk1908 schrieb:  externe HDD am Router? Klar ich tausch mein Auto gegen nen Tretroller mit Bremsklotz.
(Dieser Beitrag wurde zuletzt bearbeitet: 12.09.2015 23:30 von tk1908.)
12.09.2015 23:11
Alle Beiträge dieses Benutzers finden Diese Nachricht in einer Antwort zitieren
tk1908 Offline
Unixer

Beiträge: 7.353
Registriert seit: Apr 2009
Beitrag #17
RE: Kleines großes Routing-Problem
(12.09.2015 23:11)tk1908 schrieb:  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

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.

(12.09.2015 23:11)tk1908 schrieb:  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

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"

Keiner ne Idee?

[Bild: Rz3JNLI.gif]
Meine Beiträge stehen unter der MIT-Lizenz:D

(09.04.2016 13:26)tk1908 schrieb:  externe HDD am Router? Klar ich tausch mein Auto gegen nen Tretroller mit Bremsklotz.
14.09.2015 13:28
Alle Beiträge dieses Benutzers finden Diese Nachricht in einer Antwort zitieren
CHRiSNEW Offline
Internetblasensammler

Beiträge: 2.864
Registriert seit: Jul 2008
Beitrag #18
RE: Kleines großes Routing-Problem
Welche IP-Adresse kommt denn am NFS Server an? Ich würde fast vermuten, dass irgendwie 10.0.0.1 aufschlägt.

14.09.2015 13:35
Alle Beiträge dieses Benutzers finden Diese Nachricht in einer Antwort zitieren
tk1908 Offline
Unixer

Beiträge: 7.353
Registriert seit: Apr 2009
Beitrag #19
RE: Kleines großes Routing-Problem
(14.09.2015 13:35)CHRiSNEW schrieb:  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.

[Bild: Rz3JNLI.gif]
Meine Beiträge stehen unter der MIT-Lizenz:D

(09.04.2016 13:26)tk1908 schrieb:  externe HDD am Router? Klar ich tausch mein Auto gegen nen Tretroller mit Bremsklotz.
14.09.2015 13:41
Alle Beiträge dieses Benutzers finden Diese Nachricht in einer Antwort zitieren
CHRiSNEW Offline
Internetblasensammler

Beiträge: 2.864
Registriert seit: Jul 2008
Beitrag #20
RE: Kleines großes Routing-Problem
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

14.09.2015 14:57
Alle Beiträge dieses Benutzers finden Diese Nachricht in einer Antwort zitieren
Neue Antwort schreiben 


Gehe zu:


Benutzer, die gerade dieses Thema anschauen: 1 Gast/Gäste